Re: mkfifoat, renameat

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Jim Meyering on 9/8/2009 2:43 AM:
>> I suppose there might still be some pathological cases where renameat
>> currently fails but could be made to succeed.  For example,
>> renameat(super_deep,a,root,b) will probably fail with ENAMETOOLONG when
> 
> Speaking of pathological, ;-)
> 
> For some cases, in which a renamat emulator would fail to form *any*
> usable absolute name, it may succeed with relative names, e.g.,
> 
>   renameat(deep1,a,deep2,b)
> 
> when the deep1-relative name for deep2
> or the deep2-relative name for deep1 is short enough.
> Of course, calculating those relative names may be rather expensive.

Indeed, that's another one.  We have chdir-long which deals with some
pathological cases, but that only deals with one directory.  I'm not sure
whether it is even worth the effort to try and write a rename-long to deal
with double the directories, although enough bug reports may prod us to
try and do that.  It seems like getting two canonical directory names,
then finding the common prefix, would at least give us a start in finding
a single relative location that might work.  At any rate, I don't want to
hold up this implementation just for the pathological cases.

> Very nice.  Thanks especially for the thorough unit tests.
> 
> Have you looked at coverage data?
> It'd be nice to to ensure that each of those many cases is
> exercised on some platform.

I haven't run any profiler tool, but did step through the code by hand on
older Linux (/proc/self/fd) and  Cygwin 1.5 (save_cwd/fchdir), and
verified that I am indeed hitting all 16 combinations of absolute vs.
relative and AT_FDCWD vs. fd.  The test suite was the driver in
implementing this, and caught several early thinkos (which is the way it
should be ;)

I've pushed mkfifoat; I'm waiting to push renameat until I can finish
improving the rename module to work around cygwin 1.5 and Solaris 10
deficiencies.  Cygwin allowed rename("dir","file"), which is an absolute
no-no.  And the fact that Solaris lets rename("file1","file2/") succeed if
file2 is missing, but not if it is present, is just inconsistent,
regardless of how the Austin group rules (but preliminary feedback on my
POSIX bug report looks like others agree with me; the rename spec will
probably be tweaked so that rename("dir","name/") should be okay unless
name is an existing non-directory or an existing non-empty directory, and
rename("file","name/") should always fail).

> 
> With the full suite of portable *at functions, it should now be
> feasible to rewrite coreutils' copy.c to do its job via fts, and
> directory file descriptors, rather than via full relative names.

Well, utimensat and linkat are still on my TODO list.  With renameat in
place, linkat should be much simpler.  Should I make that testsuite also
exercise all the same paths as renameat?  Implementing utimensat will need
some thought for how best to interact with the existing utimens module and
the fact that we need rpl_utimensat on Linux to work around kernel bugs.
But I will probably complete the suite this week.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqmTZwACgkQ84KuGfSFAYBDfwCfXVrRKx5IwfNsUSTIsHSSzazm
j8AAnj2Woj9oORXB+CznMNqNk2IgiM1I
=Wouf
-----END PGP SIGNATURE-----