On Fri, Apr 03, 2015 at 03:22:29PM +0200, Nicolas George wrote: > Le quartidi 14 germinal, an CCXXIII, Mariusz Szczepańczyk a écrit : > > diff --git a/libavformat/avio.h b/libavformat/avio.h > > index f61a8f8..51913e3 100644 > > --- a/libavformat/avio.h > > +++ b/libavformat/avio.h > > @@ -63,7 +63,10 @@ enum AVIODirEntryType { > > AVIO_ENTRY_NAMED_PIPE, > > AVIO_ENTRY_SYMBOLIC_LINK, > > AVIO_ENTRY_SOCKET, > > - AVIO_ENTRY_FILE > > + AVIO_ENTRY_FILE, > > + AVIO_ENTRY_SERVER, > > + AVIO_ENTRY_SHARE, > > + AVIO_ENTRY_WORKGROUP, > > }; > > Sorry if I missed the previous discussions on the mailing list (and if not, > maybe just 8 hours before apply was a bit short for discussion), but I had a > bit of a concern with this change. > > Until know, if you wanted to make a recursive listing, you just had to know > that you had to recurse into directories. Now... should you recurse into > shares? servers? workgroups? nobody knows. > > There should be some way of knowing whether an entry can be opened like a > plain file, entered like a directory, or if it is just one of the weird > things that lay in some corners of filesystems, without requiring an update > when new types are added.
filemode could contain a bit for directories or a function could provide this information, but for example links can be both file and directory or a new field could be added to AVIODirEntry Is there a problem in the patch itself ? should it be chnaged or reverted? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel