[FFmpeg-devel] [PATCH 1/3] lavf/avio: Add new types to AVIODirEntryType, bump minor version

[Lukasz Marek]

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.