Oliver Fromme (12024-08-21):
> I'm sorry this mail is going to be rather long. However, I would
> like to explain my opinion on this matter in detail.
You are more patient than this issue deserves.
> In fact, I can rather imagine use cases to preserve the *atime*
> (access time) of the input files, rather than overriding the mtime
> of output files. So, in my opinion, an option to reset the atime
> when FFmpeg is finished would be more useful (and it would be much
> easier to implement). But I wouldn't propose it either, because it
> can be trivially done with an OS command, too.
That is not entirely true.
*Restoring* the atime can easily be done with an OS command, but it is an
aberration that will trigger an update to the ctime. Do not do that.
*Preserving* the atime cannot be done with a simple OS command, it
requires a flag on the open() system call (and corresponding
permission).
rsync has the option:
--open-noatime
This tells rsync to open files with the O_NOATIME flag (on sys‐
tems that support it) to avoid changing the access time of the
files that are being transferred. If your OS does not support
the O_NOATIME flag then rsync will silently ignore this option.
Note also that some filesystems are mounted to avoid updating
the atime on read access even without the O_NOATIME flag being
set.
But rsync is a synchronization tool, and synchronizing without altering
is a very important feature.
> (*) Well, in theory you can use FFmpeg to make a 1:1 copy (-map 0,
> same container), but even then details will usually be different
Add -f data and you will have an exact binary copy.
Regards,
--
Nicolas George
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
