Re: FYI: bug-fix: cp would fail to write through a dangling symlink

[Paul Eggert]

Jim Meyering <address@hidden> 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.