On 27/04/15 12:34, Thomas Baigneres wrote: > Hello, > > Consider the following directory hierarchy: > > $ ls -lR > total 0 > drwxr-xr-x 4 user group 136 Apr 24 13:51 source > > ./source: > total 16 > -rw-r--r-- 1 user group 0 Apr 24 13:50 file.txt > lrwxr-xr-x 1 user group 8 Apr 24 13:51 symbolic-link-to-file -> > file.txt > > > Trying to copy the `source` directory with the options -a (archive) and -l > (hard link files instead of copying) fails when using the 8.23 version > of coreutils: > > $ gcp -al source destination > gcp: cannot create hard link 'destination/symbolic-link-to-file' to > 'source/symbolic-link-to-file': Operation not supported > > Trying to do the same with the 8.22 version of coreutils works as > expected : > > $ gcp -al source destination > $ ls -lR > total 0 > drwxr-xr-x 4 user group 136 Apr 24 13:51 destination > drwxr-xr-x 4 user group 136 Apr 24 13:51 source > > ./destination: > total 16 > -rw-r--r-- 2 user group 0 Apr 24 13:50 file.txt > lrwxr-xr-x 1 user group 8 Apr 24 13:51 symbolic-link-to-file -> > file.txt > > ./source: > total 16 > -rw-r--r-- 2 user group 0 Apr 24 13:50 file.txt > lrwxr-xr-x 1 user group 8 Apr 24 13:51 symbolic-link-to-file -> > file.txt > > > Searching the internet suggests that the culprit might be the `linkat()` > function, which exists but does not work as expected by coreutils. >
Yes coreutils 8.23 uses linkat() for that where available: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.22-23-g9654b67 BTW this issue on OS X 10.10 is caught by gnulib and coreutils tests. I.E. `make check` may be being ignored on your build? There was initial work to fix this at: http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c8e57ce5 That doesn't fix everything though I think, and I'll need to look into a complete fix for Mac OS X >= 10.10 (or revert to the previous coreutils behavior). cheers, Pádraig.