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 ;-)
