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 [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
