Re: RFE: stat(1) flag for learning the d_type value of a given file

[Eric Blake]

On 10/13/2014 02:14 PM, Pádraig Brady wrote:
> On 10/13/2014 08:56 PM, Eric Blake wrote:
>> The Cygwin developers have been trying to improve some d_type hints
>> given during readdir(), to return DT_DIR instead of DT_UNKNOWN for
>> obvious directories, as an example.  But testing the patches for
>> correctness has proved to be a bit of a challenge for testing.  On an
>> IRC chat, we discovered that it is really difficult to find out what
>> d_type lists for a given file without using a debugger or writing a
>> custom program - most GNU code is using it as an optimization to avoid
>> lstat(), but never directly outputs that the optimization took place.
>> So the idea was raised: could we teach stat(1) a new format arg that
>> would make it painfully obvious what d_type hint is associated with a
>> given file?
>>
>> Of course, such a format is not trivial, and must not be part of the
>> default stat output.  Given 'stat --format=... a', you'd have to do
>> readdir() on "." until you find "a", in order to get to the d_type.  But
>> I couldn't think of any better utility to enhance to easily get at
>> d_type information from the shell.  At least, stat(1) feels like a
>> better choice than ls(1) for adding the enhanced output information.
>>
>> What do you think? Should I spend time writing up a patch?
> 
> Maybe, though coreutils' tests also check d_type is available.
> Would this suffice for cygwin?
> 
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=tests/d_type-check;hb=HEAD

That seems like a useful starting point for a hack, but it's a bit too
platform-specific (libc = ctypes.cdll.LoadLibrary("libc.so.6") has no
chance on Cygwin, and even hardcoding the assumption that DT_DIR==4 is a
bit risky, although it works for Cygwin).  The fact that it takes that
much effort in python is making me like the idea of a stat format
modifier even more, especially since d_type exists on multiple platforms.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature