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

[tg at mirbsd dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=20720

Thorsten Glaser <tg at mirbsd dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tg at mirbsd dot de

--- Comment #1 from Thorsten Glaser <tg at mirbsd dot de> ---
This bugreport appears legit, but the expected output is not:

tg@blau:~ $ ./x
Processing f2 in working dir /tmp/stest_dir/d1
Processing d1 in working dir /tmp/stest_dir
Processing f1 in working dir /tmp/stest_dir
Processing stest_dir in working dir /home/tg
Oops...relative path does not exist in current directory: No such file or
directory

Rationale:

When dropping FTW_DEPTH (post-order), the output (on BSD) is the same
as above, just reversed, as it should be:

Processing stest_dir in working dir /home/tg
Oops...relative path does not exist in current directory: No such file or
directory
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

The (BSD) documentation for nftw(3) states that:

     FTW_CHDIR  Change to a directory before reading it. By default, nftw()
                will change its starting directory. The current working direc-
                tory will be restored to its original value before nftw() re-
                turns.

So, the initial path (/tmp/stest_dir) can be returned before the
/tmp/stest_dir directory itself needs to be read (as it is read
from /tmp, not from /tmp/stest_dir), so nftw() does not need to
chdir() into /tmp/stest_dir before emitting /tmp/stest_dir, and
requesting it to chdir() into /tmp *at all* during processing
of your request is actively wrong.

By the way, open() takes three arguments when O_CREAT is used,
so, strictly speaking, your testcase is undefined.

-- 
You are receiving this mail because:
You are on the CC list for the bug.