[FFmpeg-user] How to preserve file time

[James Ralston]

On Mon, Aug 19, 2024 at 6:41 AM Reindl Harald <h.reindl at thelounge.net> wrote:

> Am 19.08.24 um 07:56 schrieb James Ralston:
>
> > The fact that ffmpeg does it this way [queries for the existence
> > of the output file itself) is a bug (albeit perhaps one of
> > convenience, since ffmpeg supports more operating systems than just
> > Unix/Linux)
>
> it doesn't at all
> with "-y" it just opens the file and that's it

I don’t understand what you’re attempting to refute.

ffmpeg *always* overwrites the output file, because none of the
functions that ultimately call avpriv_open() in libavutil/file_open.c
set O_EXCL in the flags to open().

ffmpeg *attempts* to prevent the user from overwriting an preexisting
output file, but it does so incorrectly, by manually testing for the
existence of the output file (unless -y is given) and (if stdin is
connected to a tty) prompting the user what to do.  Especially if the
user is prompted, this leaves an enormous window for a race condition
to occur.

The *correct* way to implement a safety feature for not overwriting a
preexisting output file is to do one and only one of the following:

1. If -y is specified, omit O_EXCL from the flags to open(); otherwise
   always include O_EXCL.  Remove the -n flag.

2. If -n is specified, include O_EXCL in the flags to open();
   otherwise never include O_EXCL.  Remove the -y flag.

Choice #1 (don’t overwrite unless the invoker declares it is
permissible to do so) matches the current (incorrectly-implemented)
behavior.

I suspect the reason why ffmpeg implements its current (incorrect)
behavior is because Windows lacks the Unix/Linux equivalent of O_EXCL.

But I would argue that in that case the correct answer is to remove
the race condition (that is, rip out the manual check), correctly use
O_EXCL on Unix/Linux systems, and tell Windows users that they should
use a better OS if they want to ensure that preexisting output files
aren’t overwritten.

Introducing a race condition (with potential security implications) to
compensate for an inadequate OS functionality is rarely a good choice.