[FFmpeg-devel] [PATCH 3/9] lavf/file: implement EXCL flag.

[Nicolas George]

Le decadi 30 germinal, an CCXXII, Reimar Döffinger a écrit :
> I didn't properly understand what it does.
> The name EXCL tricked my mind into thinking it would also be about exclusive
> access/locking (I had been thinking about that for other reasons).
> To me that raises the question: Do we really want to take over the
> horrible O_EXCL naming or should we rather call it something more
> descriptive?

I implicitly thought that people were familiar enough with the Unix/POSIX
API to understand it immediately. It seems my assumption was wrong, sorry
for the wasted time.

Under that assumption, reusing the name made sense, even if it is
ill-advised, but since it is not true, there is no reason for it. Would
AVIO_FLAG_NO_OVERWRITE(_LOOSE) make sense?

> Also, will this feature ever work reliably actually?
> It might create a false sense of security, which actually not working
> without any possibility to even detect the cases where it does not work
> (at least that's my impression reading the man page, and that's only for
> files).

O_EXCL does not work with very old NFS clients or servers. Apart from that,
AFAIK, it works, and it is used by a lot of applications. If someone is
using old NFS, then their whole system is unsafe.

That was for files. For other protocols, that depends. For a lot of
low-level protocols, it just does not make sense: you connect to a TCP
server, it does not mean anything to wonder if you are creating /
overwriting / truncating the data. That is the reason for the lot of small
patches adding the flag on this kind of protocols.

For protocols where it makes sense, there is some work to do to map the AVIO
flag to the corresponding feature in the protocol. Some protocol will lack
the required feature, that just means they are unsuited to safely create
files without overwriting.

That is the reason I add a flag to the protocol structure and propose the
EXCL and the EXCL_LOOSE variants: the EXCL variant is careful and will fail
on protocols where the feature is not yet implemented or can not be
implemented reliably, making it safe but less practical; the LOOSE variant
does the opposite.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140419/fed68b35/attachment.asc>