This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/20720] ntfw with FTW_CHDIR and FTW_DEPTH can't back out of a tree properly giving ENOENT

--- 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]