[FFmpeg-devel] [PATCH 3/9] lavf/file: implement EXCL flag.
george at nsup.org
Sat Apr 19 10:49:02 CEST 2014
Le decadi 30 germinal, an CCXXII, Reimar Döffinger a écrit :
> Sorry for being too lazy to check the source, but maybe you know it:
> Will this work on Windows?
> If no, should we implement it?
The ".flags = URL_PROTOCOL_FLAG_EXCL" part is also protected by "#ifdef
O_EXCL". On systems lacking O_EXCL, that means creating files will always
fail in strict mode and work with the unreliable check-then-create in loose
mode. Not completely satisfactory, but at least not a security concern.
And, of course, it only affects situations where AVIO_FLAG_EXCL* is used.
For now, the only affected case would be tools/aviocat if the user sets the
The flag could later be used to make the overwrite check in ffmpeg ("File
'foo' already exists. Overwrite ?") more reliable, but only once it is
stable and tested enough.
> If yes, isn't it confusing to default to non-exclusive even though the
> whole OS defaults to exclusive?
I am not sure what you mean here, especially "exclusive" and
"non-exclusive". As far as I know, currently, lavf will silently overwrite
files on any platform, and this patch series does not change the default.
I can explain why I wrote that series now: I intend to write an
"attachments" muxer that would dump each attachment into a file, based on
the attachment name. For example:
ffmpeg -i fansub.mkv -f attachments -map 0:t fonts/
to extract all attachments in a Matroska file into a directory.
Such an option would be severely dangerous, because a crafted file could
have an attachment named ../../.ssh/authorized_keys for example. I intend to
document it as such with prominent warnings in the documentation, but an
extra safety is a good thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel