Re: Running of rrequested tests - [was Re: Backup problem using "cp"]
On Tue 08 May 2018 at 11:38:52 (-0400), The Wanderer wrote:
> On 2018-05-08 at 11:10, Richard Owlett wrote:
>
> > On 05/07/2018 07:01 AM, Thomas Schmitt wrote:
> >
> >> Hi,
> >>
> >> Richard Owlett wrote:
> >>> richard@debian-jan13:~$ stat / | fgrep Device
> >>> Device: 80eh/2062d Inode: 2 Links: 22
> >>> richard@debian-jan13:~$ stat /media | fgrep Device
> >>> Device: 80eh/2062d Inode: 131073 Links: 5
> >>
> >> "/media" was not the directory to examine.
> >> You need to examine the directory which you gave as second argument to cp.
> >> In your initial post of this thread the cp command is quoted as
> >>
> >> cp -ax / "/media/richard/MISC
> >> backups/dev_sda14/"
> >>
> >> (Dunno whether the line break in that mail is significant.)
> >> [SNIP]
> >
> > The line break was an email artifact and have changed partition label to
> > prevent future confusion.
> >
> > This is the output of script command:
>
> <snip>
>
> Have you tried
>
> stat /home/richard/.local/share/Trash/expunged/1449727740/grub2
> problem-2018-02-13/
>
> and/or a 'ls' of the same directory?
>
> Since we've apparently confirmed that /media/richard/MISC-backups/ is on
> a separate filesystem from /, it really looks to me as if this too-deep
> directory chain may exist within the source tree, in some form.
It's unwise to distrust cp -x without a *lot* more evidence.
> The only comment I've found from you on this point seems to be a
> statement that yes, such a chain existed, but after you deleted it, it
> came back the next time you tried the copy.
Reiterating my question: what's the evidence that anything has
been deleted? "Emptied the trash" was the phrase used.
> If that's correct, then there must be something intervening to cause the
> chain to be re-created; the cp command should not be capable of
> modifying its source argument, unless its destination is under its
> source (which would obviously cause problems).
>
> If it's not correct, then I'd be interested to know what is in fact
> there, and what might have caused it to exist (or not).
Recreating these directories is problematical. Whatever created them
happened on the morning of the first Tuesday in March. They could
only come back from the dead by being copied from yet another copy.
(Look at the file modification dates.)
So I think they've existed all the time. It might be interesting to
know what else has timestamps in that period. The find command can
do that rather easily with its -newer and -not switches.
Cheers,
David.
Reply to: