On Mon 07 May 2018 at 09:11:08 (-0500), Richard Owlett wrote: > 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.
I read these words, but have no idea what events actually take place. > 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...". ' What would interest me is a listing of these files (including their inodes (-i) too): /home/richard/.local/share/Trash/expunged/73080846/ /home/richard/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13/ /home/richard/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13/grub2 problem-2018-02-13/ Cheers, David.