Web lists-archives.com

Re: Running of rrequested tests - [was Re: Backup problem using "cp"]

On 05/08/2018 10:38 AM, The Wanderer wrote:
On 2018-05-08 at 11:10, Richard Owlett wrote:

On 05/07/2018 07:01 AM, Thomas Schmitt wrote:


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

(Dunno whether the line break in that mail is significant.)

The line break was an email artifact and have changed partition label to
prevent future confusion.

This is the output of script command:


Have you tried

stat /home/richard/.local/share/Trash/expunged/1449727740/grub2

and/or a 'ls' of the same directory?

After adding required quotation marks:
richard@debian-jan13:~$ stat "/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13/"
  File: /home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13/
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 80eh/2062d	Inode: 141462      Links: 3
Access: (0700/drwx------)  Uid: ( 1000/ richard)   Gid: ( 1000/ richard)
Access: 2018-05-08 08:10:45.509914304 -0500
Modify: 2018-03-06 09:41:14.972933512 -0600
Change: 2018-05-07 04:50:02.664296985 -0500
 Birth: -
richard@debian-jan13:~$ ls "/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13/"
grub2 problem-2018-02-13

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.

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.

That is correct.
Also I did the same before running today's test.

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).

Me to ;/