This is the mail archive of the
mailing list for the glibc project.
[Bug libc/20720] ntfw with FTW_CHDIR and FTW_DEPTH can't back out of a tree properly giving ENOENT
- From: "john.ata at baesystems dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 19 Oct 2016 22:10:12 +0000
- Subject: [Bug libc/20720] ntfw with FTW_CHDIR and FTW_DEPTH can't back out of a tree properly giving ENOENT
- Auto-submitted: auto-generated
- References: <email@example.com/bugzilla/>
--- Comment #2 from John Ata <john.ata at baesystems dot com> ---
>> This bugreport appears legit, but the expected output is not
This output was obtained on Linux (both RHEL 7 and Mint 17.3). I didn't test
on BSD. Your BSD output clearly is different than what Linux is providing.
>> When dropping FTW_DEPTH (post-order), the output (on BSD) is the same
as above, just reversed, as it should be:
I'm not understanding your message regarding removing FTW_DEPTH so forgive me
if I'm stating the obvious or missing your point - this bug is defined when
FTW_DEPTH is included *with* FTW_CHDIR. If you remove FTW_DEPTH, it actually
works on both RHEL and Mint without error. From my home directory (not /tmp) I
Processing stest_dir in working dir /tmp
Processing d1 in working dir /tmp/stest_dir
Processing f2 in working dir /tmp/stest_dir/d1
Processing f1 in working dir /tmp/stest_dir
FTW_DEPTH instructs nftw to process a directory's contents before processing
the directory itself. In order to process the contents, it needs to change
directories since FTW_CHDIR was specified, process the contents, and then back
out before processing the directory. If FTW_DEPTH is not specified, then the
directory will be processed first before changing directories and there won't
be a problem. However, when specifying FTW_DEPTH, it is important to change
working directories back to /tmp before processing stest_dir - it's the only
way one can process stest_dir.
From the manpage:
If set, do a post-order traversal, that is, call fn() for the
directory itself after handling the contents of the directory and
its subdirectories. (By default, each directory is handled
before its contents.)
>> Processing stest_dir in working dir /home/tg
This seems like a flaw on BSD - there is no stest_dir in /home/tg if you ran my
test and didn't have one their by chance. Only one in /tmp. The Linux version
of glibc does it correctly.
Regarding the third argument to open, technically yes (note that the test case
doesn't actually do I/O to any of the files involved, only a stat()).
You are receiving this mail because:
You are on the CC list for the bug.