Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> However, I don't like using canonicalize_filename_mode, partly >> for its internal "xmalloc". Technically, copy.c aspires to "librarihood", >> so it is not supposed to exit on OOM errors, but there is precedent there, >> and I'm not going to fix *that* right now. >> Also, it would be subject to the PATH_MAX name length limitation. >> Another thing not to like: it may use xgetcwd. Here, we generally >> don't need the entire absolute name. > > Yes, it's total overkill for this application. Another thing: we > don't need to resolve internal symlinks, just the last one.
Why would we want to resolve *any* of them, if we can get the dir-fd, ent-name pair I mentioned? >> FYI, here's the canonicalize_filename_mode-based solution: > > That patch is not quite right, since the CAN_ALL_BUT_LAST flag that I Hmm... I did at least try to test it. And it seemed to pass. I confess I spent very little time on it, so maybe the test is wrong, too. Will investigate tomorrow. > suggested earlier turns out to be wrong; we need CAN_MISSING. But in > rereading the code I see there's a more systematic problem here. > > POSIX says that -H -L -P etc affect only source symlinks; destination > symlinks are always followed. (Ouch! maybe we need an option to > override this, but right now let's just get the standard behavior > working.) And yet in several places 'cp' refuses to follow symlinks > in the destination, e.g., it uses lstat where it should use stat. > > Fixing this carefully will require a bit of thinking; I am a bit > stressed for time right now so it may be a couple of days. Some of my > earlier comments about looking at x->dereference were wrong, but they Ahhh. I'm relieved. I wondered about that one (seemed backwards), but didn't make time to investigate. > were based on some existing coreutils code that I think is wrong in > this area as well. Oh! Then I'll hunt for it tomorrow if you don't tell first. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
