On Mon, Aug 19, 2024 at 6:41 AM Reindl Harald <h.rei...@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. _______________________________________________ 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".
