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:
> >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.
Reply to: