This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients hynek, ncoghlan, neologix, pitrou, rosslagerwall, tarek
Date 2012-01-08.15:25:48
SpamBayes Score 5.48585e-11
Marked as misclassified No
Message-id <>
In-reply-to <1326030840.3374.5.camel@localhost.localdomain>
Here's a possible walkfd() implementation.

$ cat /home/cf/
import os
import sys

topfd =[1], os.O_RDONLY)

for rootfd, dirs, files in os.walkfd(topfd):
    print(rootfd, dirs, files)
$ ./python ~/ /etc/apt/
3 ['sources.list.d', 'preferences.d', 'trusted.gpg.d', 'apt.conf.d']
['trustdb.gpg', 'trusted.gpg~', 'sources.list', 'trusted.gpg']
4 [] []
4 [] []
4 [] []
4 [] ['70debconf', '01autoremove', '00trustcdrom']
[44194 refs]

AFAICT, a safe rmtree could be implemented simply with
walkfd(topdown=False), but Antoine's remarks make me thing I missed

> Be aware that you have to manage dirfd's lifetime, which can make things
> interesting.

Basically, this means that doing:
for rootfd, dirs, files in walkfd(topfd):
    print(fstat(rootfd), dirs, files))

is valid whereas

print([(fstat(rootfd), dirs, files) for (rootfd, dirs, files) in
walkfd(topfd)]) isn't.

> Also be aware that symlinks mean sometimes you won't have a dirfd: if
> you have a symlink that points to another directory, you can't open that
> directory using openat from the symlink's directory. So if you follow
> symlinks (or have an option to do so) you must also take that case into
> account.

I'm not sure I understand this. Why "you can't open that directory
using openat from the symlink's directory". Could you elaborate?
File name Uploaded
walkfd.diff neologix, 2012-01-08.15:25:47
Date User Action Args
2012-01-08 15:25:49neologixsetrecipients: + neologix, ncoghlan, pitrou, tarek, rosslagerwall, hynek
2012-01-08 15:25:48neologixlinkissue13734 messages
2012-01-08 15:25:48neologixcreate