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@raven> ls -l test_symlink total 0 lrwxrwxrwx 1 software software 3 Nov 30 13:29 new -> old software@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@raven> cat test_symlink.cmake file(COPY test_symlink/ DESTINATION test_symlink1) software@raven> ls -l test_symlink total 0 lrwxrwxrwx 1 software software 3 Nov 30 13:29 new -> old software@raven> rm -rf test_symlink1 software@raven> cmake -P test_symlink.cmake software@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 __________________________ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
