Hi, Andy Smith wrote: > It would still be good to establish why "cp -x" was seemingly able > to cross filesystem boundaries as that would be a bug.
Yep. Leaving behind too many maybe-bugs can make the ground swampy. I forgot to mention that the theory of David Wright is not outruled yet: David Wright wrote: > The loop is generating a source filename > /home/richard/.local/share/Trash/expunged/73080846/grub2 > problem-2018-02-13/grub2 problem-2....018-02-13/grub2 problem-2018-02-13 > which is likely within length limits, and resides on the correct > filesytem. Loop and size overflow could indeed have been separated. - First some step-on-own-foot loop would have created the deep directory tree until it failed due to path size. May have happened months ago. Now barely legal paths are lurking. - This would then cause another failure when a non-looping copy attempt lengthens the path by prefix "/media/richard/MISCbackups/dev_sda14". Richard would have to check whether there is such a deep tree on the disk that shall be source of the copy. Have a nice day :) Thomas
