[FFmpeg-user] feature proposal - avoid overwriting the input file

[Mikhail V]

James Girotti wrote:

> On Tue, Oct 10, 2017 at 4:40 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>
> > Currently it is possible to delete the input file if I specify same
> > filename in output,
> > for example:
> >
> > ffmpeg -y -i input input
> >
>
> Aren't you specifying that with '-y' you want to "overwrite output file
> without asking"

Sure, I am. But anybody can miss the typo, and its not so easy to
notice in console or text editor, its just two chars
in a pile of chars.

>
>
> > or simply:
> > ffmpeg -i input input
> > (this will promt y/n)
> >
>
> I believe this is the default behavior for any output file that is present
> whether it matches input or not (in my example both foo.mkv and bar.mkv
> file present):

I see your point, yes I can do it with any existing file so there is no
fool-proof for general case.
But you know, if I delete some wrong output file, then still I have some
consolation because I don't lose the input file :)
Losing some random output file is not so bad usually from my
experience because I probably notice somthing gone wrong within short time
 and sources for that file still (hopefully) exist.


> > Was quite funny actually :) Funniest thing that I could not recover the
> > file
> > because it is same name.
> >
>
> That reminds me of when I accidentally did 'rm -rf /*'

Yeh, wrong batch renaming can cause  a lot of interesting
situations.

> >
> > So, it would be nice if ffmpeg compare the output path with all input paths
> > and exit with an error.
> >
>
> Is it possible for you to run your command without '-y' or if you're using
> a script, then to compare your input and output before passing them to
> ffmpeg?

Actually this happened to me without '-y'. That time I have
just reflexively typed 'y' and enter when prompted [Y/N].
And I can understand because this reflex of mine was trained by
doing a lot of trial-and error encodings in the past. In batch scripts
I never use '-y'
options.
Probability of such accident raises when copy-pasting file paths
from a file manager into ready full command line strings.

And what I am wondering, what can be really *against* such
feature.