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. > FYI, here's the canonicalize_filename_mode-based solution: That patch is not quite right, since the CAN_ALL_BUT_LAST flag that I 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 were based on some existing coreutils code that I think is wrong in this area as well. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
