hardlinks and cp -R (original) (raw)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

It's been 9 years, but I still don't feel comfortable with the outcome of: http://lists.gnu.org/archive/html/bug-coreutils/2004-08/msg00054.html

$ rm -rf 1 2; mkdir -p 1/d 2/d $ echo foo > 1/d/1; ln 1/d/1 1/d/2; ln 1/d/1 1/d/3 $ echo foo > 2/d/1 $ echo bar > 2/d/2; ln 2/d/2 2/d/3; ln 2/d/2 2/d/4

$ grep . {1,2}/d/* 1/d/1:foo 1/d/2:foo 1/d/3:foo 2/d/1:foo 2/d/2:bar 2/d/3:bar 2/d/4:bar

$ cp -R 2/d 1 $ diff -ur 2 1 diff -ur 2/d/1 1/d/1 --- 2/d/1 2013-08-17 00🔞06.786991409 +0100 +++ 1/d/1 2013-08-17 00🔞31.931010671 +0100 @@ -1 +1 @@ -foo +bar

The order matters greatly here; whichever of 1/d/{1,2,3} is written to last will win, by virtue of being hard-linked. As the source files have different contents, we can have different outcomes depending how getdents(2) chooses to order the files.

Should I expect to get the same result as "rsync -aA 2/d 1"? Is it my own risk for failing to ask for --preserve=links or --remove-destination? As we're firmly in POSIX-land, what does POSIX say, and could cp do anything other than its current behaviour (nothing requires or forbids reordering in 2.f - "The files in the directory source_file shall be copied ...")

Cheers, Phil

• hardlinks and cp -R,Philip Rowlands <=

• Prev by Date:cp: add support for preserving ext2 attributes
• Next by Date:Re: cp: add support for preserving ext2 attributes
• Previous by thread:cp: add support for preserving ext2 attributes
• Next by thread:process the output of $() with files with spaces
• Index(es):
  • Date
  • Thread