[Python-Dev] PEP 471 (scandir): Add a new DirEntry.inode() method?

Cameron Simpson cs at zip.com.au
Sat Feb 14 04:15:44 CET 2015


On 14Feb2015 11:35, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>Victor Stinner writes:
> > *** Now the real question: is it useful to know the inode number
> > (st_ino) without the device number (st_dev)? ***
> >
> > On POSIX, you can still get the st_dev from DirEntry.stat(), but it
> > always require a system call. So you loose the whole purpose of
> > DirEntry (no extra syscall).
>
>True, but I suppose in many cases the user will know that all file
>system objects handled are on the same device, or will be willing to
>risk an occasional anomoly.

In POSIX, all filsystem objects named by a directory are on the same device 
unless one is a mount point. (And in that case, d_ino from stat won't match 
d_ino from scandir; I expect.)

>IMO: Document the limitation (if no extra syscall) or inefficiency
>(with the syscall), and let the user choose.

+1 on .inode(): d_ino has been available in the directory data on POSIX since 
at least V7 UNIX (1970s), almost certainly earlier. Agree the limitation should 
be mentioned.

>The remaining issue is whether to provide a convenience function for
>the device number, with appropriately loud warnings about how
>inefficient it is, or to deter the user with the need to call .stat()
>and extract the device number.

-1 on that. People will use it! Given the doco above, it should be obvious 
under what circumstances one might choose to call stat, and making that stat 
overt means it is less likely to be called unwisely.

Since scandir is all about efficiency, providing a very costly convenience 
function seems to go against the grain.

Regarding usefulness: Victor, you've got the typical use case in another post 
(i.e. useful as in "advantageous"), and your own tests show that st_dev of the 
dir matches st_dev of a dir's entries in all normal/regular filesystems (i.e.  
useful as in "meaningful/consistent").  Special filesystems like /dev may be 
weird, but people relying on this should be aware of the constraint anyway.  
Since a directory at the low level is essentially a mapping of names to inodes 
within the directory's filesystem, this is to be expected.

Cheers,
Cameron Simpson <cs at zip.com.au>

Uh, this is only temporary...unless it works.   - Red Green


More information about the Python-Dev mailing list