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:
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?
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
richard@debian-jan13:~$
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 ;/
