Re: Backup problem using "cp"
- Date: Mon, 7 May 2018 20:18:37 -0500
- From: David Wright <deblis@xxxxxxxxxxxxxxxxx>
- Subject: Re: Backup problem using "cp"
On Mon 07 May 2018 at 09:11:08 (-0500), Richard Owlett wrote:
> On 05/07/2018 08:49 AM, Thomas Schmitt wrote:
> >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
> >>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
> >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/grub2 problem-2018-02-13/grub2 problem-2018-02-13/