[cmake-developers] [CMake 0014609]: cmake -E copy and cmake -E copy_directory commands need an option to NOT follow symlinks on Linux

[Alan W. Irwin]

On 2013-11-30 18:41-0500 Mantis Bug Tracker wrote:

>
> The following issue has been SUBMITTED.
> ======================================================================
> http://public.kitware.com/Bug/view.php?id=14609
> ======================================================================
> Reported By:                irwin
> Assigned To:
> ======================================================================
> Project:                    CMake
> Issue ID:                   14609
> Category:                   CMake
> Reproducibility:            always
> Severity:                   minor
> Priority:                   normal
> Status:                     new
> ======================================================================
> Date Submitted:             2013-11-30 18:41 EST
> Last Modified:              2013-11-30 18:41 EST
> ======================================================================
> Summary:                    cmake -E copy and cmake -E copy_directory commands
> need an option to NOT follow symlinks on Linux
> Description:
> It is known but not documented (see bug 13204) that both "cmake -E copy" and
> "cmake -E copy_directory" currently follow symlinks on Linux.  This results in a
> particularly bad situation when attempting to copy a directory that happens to
> contain a broken symlink, e.g.,
>
> software at raven> ls -l test_symlink
> total 0
> lrwxrwxrwx 1 software software 3 Nov 30 13:29 new -> old
>
> software at raven> cmake -E copy_directory test_symlink test_symlink1
> Error copying directory from "test_symlink" to "test_symlink1".
>
> When I encountered this much too generic error message when using copy_directory
> for a very large directory recently I initially had no idea whether I was
> dealing with an i/o error or whatever, and it is only by chance that I
> discovered a botched exit from emacs in that directory had created a broken
> symlink.
>
> Thus, at minimum bug 13204 should be fixed and also copy_directory (and copy)
> should have a much more specific error message identifying both the symlink and
> the non-existent file that is causing the trouble.
>
> In addition, a (Unix-only) option to NOT follow symlinks should also be
> implemented for copy_directory and copy.  After all, every GNU utility by
> default does not follow symlinks on Unix so it would be nice if at least this
> option was implemented for the cmake -E copy_directory and cmake -E copy
> commands on Unix.
> ======================================================================
>
> Issue History
> Date Modified    Username       Field                    Change
> ======================================================================
> 2013-11-30 18:41 irwin          New Issue
> ======================================================================
>

I am copying a further note I made for bug 14609 here (on the
cmake-devel mailing list) in the hope it will inspire someone here
with knowledge of the CMake code to make it a priority to deal with
this bug as well as bug 13204.

Following a tip in the comments to bug 13204, I confirmed that
code (again undocumented concerning what it does with symlinks)
already exists in cmake to NOT follow symlinks.  Here is an example:

software at raven> cat test_symlink.cmake
file(COPY test_symlink/ DESTINATION test_symlink1)
software at raven> ls -l test_symlink
total 0
lrwxrwxrwx 1 software software 3 Nov 30 13:29 new -> old
software at raven> rm -rf test_symlink1
software at raven> cmake -P test_symlink.cmake
software at raven> ls -l test_symlink1
total 0
lrwxrwxrwx 1 software software 3 Dec  1 11:22 new -> old

Still another treatment of symlinks is implemented by the
file(GLOB_RECURSE ... signature) which by default does not follow
symlinks but which has a FOLLOW_SYMLINKS option.

So CMake is a rather self-contradictory mess right now with how it treats
symlinks; some commands (e.g., the -E copy and -E copy_directory
commands) always follow symlinks, some commands (e.g., the file(COPY
...) command) never following symlinks, and at least one command (the
file(GLOB_RECURSE ...) command) by default does not follow symlinks
but has a FOLLOW_SYMLINKS option.  Of course, those contradictory
symlink treatments mean that the fundamental implementations already
exist to pick just one model for dealing with symlinks in all cases.
So, in principle, it should be straightforward to implement that.

When picking the model for the preferred treatment of symlinks, I
would advocate following the file(GLOB_RECURSE ...) model in all cases
since that model is similar to how the GNU tools treat symlinks and
therefore causes the least surprise for Unix users.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________