[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