Re: mkfifoat, renameat

[Jim Meyering]

Eric Blake wrote:
> 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.

Of course.  There's no reason to hold out for those.
It's impossible to hit them with modern systems, so I might argue
that robustness, solely for nearly obsolescent systems (or those
like mingw), is not worth the effort.

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

If you have the time and energy to write the tests, I certainly
won't try to dissuade you ;-)