On 03.04.2015 16:19, Michael Niedermayer wrote:
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
Fortunately this is not an issue for samba as it returns link's target
type. Mariusz has sent email to their mailing list with question about
this strange links treatment. But this have to be handled somehow for
next protocols. It cannot be a bit in filemode, because filemode may be
unknown and is set to -1 in this case.
I am not convinced that all enums that can be listed recursively has to
be marked explicitly. If thats just a case of symlink, then extending
struct with target's type and target's path may be more useful and also
solves the issue.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
