Hi, Richard Owlett wrote: > > I thought I had broken the loop by specifying -x.
Jonathan Dowland wrote: > This is one excellent illustration of why cp is the wrong tool for this > job. cp -ax is not at fault, as it seems. The reason for the problem has been identified as a file path on the original disk which has nearly maximum length and went over the edge when a 37 byte prefix was added to get a path on the backup disk. It is yet unclear why the deep tree branch exists on the original disk. Maybe result of a symbolic link loop and copying with link resolution. Although i suspect cp to be able to detect link loops. It's not such an unusual pitfall and the GNU core utilities surely have seen lots of interesting situations. So maybe it's the result of a buggy program which wanted to create one directory with the name "grub2 problem-2018-02-13" and ended up creating 161 of them. Have a nice day :) Thomas
