Web lists-archives.com

Re: Backup problem using "cp"




On 05/07/2018 08:49 AM, Thomas Schmitt wrote:
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.

It was. I deleted. I emptied trash. It reappeared on my next run of cp.
My machine is still tied up and haven't rerun 'Check the device numbers of "/" and "/media/richard/MISC...". '