Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Richard Owlett]

On 05/11/2018 02:47 PM, Pascal Hambourg wrote:

Le 11/05/2018 à 19:54, Richard Owlett a écrit :


I posted after having purged my system of the offending  and was 
writing from memory.


I believe there were two source directories
    /home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13

 and
 /root/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13
or
 /home/root/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13


Probably /root/... /home/root usually does not exist.


Looked further just now
Perhaps should have been:
  /home/root/...




The crud filled result was a "THING/glob/???" at:
 /media/richard/MISC  backups/dev_sda14/home/richard/.local/share
   /Trash/expunged/73080846/grub2 problem-2018-02-13


That is the result of the copy from /home/richard/. What makes you think 
that the directory tree in /root was involved ?


Grasping at straws 
;/





What I was trying to document was that
 cp -ax /  /media/richard/MISC-backups/dev_sda14/root
should be have been expected to run to _intended result_.

In reality, there was a *PERVERSE* permutation of initial conditions.


I do not understand what you mean.


Makes two of us



IIUC, the error was caused by a very long pathname in the source path 
which exceeded the maximum length in the target path. After you removed 
the overlong directory chain, cp proceeded without error as expected.

Or did I miss something ?


Possibly. Just trying to explain things "After the Fact" [rofl]

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Richard Owlett]

On 05/11/2018 12:35 PM, Gene Heskett wrote:

[rofl]

I suspect, if we could get Richard to talk, that he too was a nerd before
the word was invented. Maybe, but he got a later start...


ROFL
My father was an EE, My mother an RN
Married day before Pearl Harbor

nuff said ;/

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Pascal Hambourg]

Le 11/05/2018 à 19:54, Richard Owlett a écrit :


I posted after having purged my system of the offending  and was 
writing from memory.


I believe there were two source directories
    /home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13

     and
     /root/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13
or
     /home/root/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13


Probably /root/... /home/root usually does not exist.


The crud filled result was a "THING/glob/???" at:
     /media/richard/MISC  backups/dev_sda14/home/richard/.local/share
   /Trash/expunged/73080846/grub2 problem-2018-02-13


That is the result of the copy from /home/richard/. What makes you think 
that the directory tree in /root was involved ?



What I was trying to document was that
     cp -ax /  /media/richard/MISC-backups/dev_sda14/root
should be have been expected to run to _intended result_.

In reality, there was a *PERVERSE* permutation of initial conditions.


I do not understand what you mean.

IIUC, the error was caused by a very long pathname in the source path 
which exceeded the maximum length in the target path. After you removed 
the overlong directory chain, cp proceeded without error as expected.

Or did I miss something ?

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Richard Owlett]

On 05/11/2018 09:46 AM, Pascal Hambourg wrote:

Le 11/05/2018 à 14:59, Richard Owlett a écrit :

On 05/06/2018 09:22 AM, Richard Owlett wrote:
I'm attempting to backup current partition  to a USB connected 1 TB 
drive.


I get:

root@debian-jan13:/home/richard# cp -ax / "/media/richard/MISC 
backups/dev_sda14/"
cp: cannot stat '/media/richard/MISC 
backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13': File name too long




The problem turned out to be that 
"local/share/Trash/expunged/73080846/grub2..." appeared under *BOTH*

/home/richard and the root directory.


Do you mean that there was a

/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13

or

/root/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13

directory ? The former would be really odd. Also, I do not see how 
either would interfere with


/media/richard/MISC 
backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13 



or

/home/richard/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13


I posted after having purged my system of the offending  and was 
writing from memory.


I believe there were two source directories
   /home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13

and
/root/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13
or
/home/root/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13


The crud filled result was a "THING/glob/???" at:
/media/richard/MISC  backups/dev_sda14/home/richard/.local/share
  /Trash/expunged/73080846/grub2 problem-2018-02-13




I successfully ran:
root@debian-jan13:/home/richard# updatedb
root@debian-jan13:/home/richard# locate TRASH
root@debian-jan13:/home/richard# cp -ax / 
/media/richard/MISC-backups/dev_sda14/


None of these commands removes any file or directory.



Agreed ;/
There had been a mess of house keeping done.

What I was trying to document was that
cp -ax /  /media/richard/MISC-backups/dev_sda14/root
should be have been expected to run to _intended result_.

In reality, there was a *PERVERSE* permutation of initial conditions.

Now can you understand why *I* am fascinated with "corner cases" ;/

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Gene Heskett]

On Friday 11 May 2018 11:28:08 Curt wrote:

> On 2018-05-11, Richard Owlett  wrote:
> > On 05/11/2018 08:13 AM, to...@tuxteam.de wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On Fri, May 11, 2018 at 07:59:30AM -0500, Richard Owlett wrote:
> >>> On 05/06/2018 09:22 AM, Richard Owlett wrote:
> >>
> >> [...]
> >>
> >>> I've been introduced to many commands and some of the "logic" of
> >>> the Linux way of doing things.
> >>>
> >>> Thanks everybody.
> >>
> >> Thanks for keeping things interesting & fun with your (sometimes
> >> whimsical ;-) enquiries.
> >
> > I don't recall being whimsical.
> > Weird. Possibly. Been told that for >70 years ;}
>
> Yeah. And one man's fun and interesting is another man's so narrow and
> exiguous a corner case no one but Owlett himself could possibly fit
> into it.

But he is not quite alone in his corner. I was about 8 years old when I 
asked my uncle, who made his beer money fixing the "all American" 5 tube 
radios of the day (this was about 1942) what was wrong with the waxed 
paper sealed electrolytic capacitor he had just changed. He didn't know  
but pulled a cabinet door open that had a hand written menu on it 
titled;
IF
and one  of the lines said "it hums, change the filter caps." But that 
didn't tell me why and I was full of why's.

So on my mothers (she had the distinction of being the only girl in the 
1929 class on aviation technology at Des Moines Tech High School, and if 
she didn't know the answer to my questions, she did know where the 
library was) next trip to town, she hit the library and brought home a 
couple books that were state of the art in 1942, about high school 
physics. One chapter was on capacitance and how it was made. So on our 
next Sunday trip to Des Moines, I blew my uncle away by telling him what 
was wrong with those capacitors. That of course got me introduced to his 
collection of sci-fi books. And generated a lifelong passion for things 
technical.

With an 8th grade education, I have made my living in some field of 
electronics since I was 13, and retired from a tv station in June 2002 
as the Chief Engineer, a chair I didn't spend a lot of time in but had 
it for 18 years. Nothing went out of the building to be repaired during 
my tenure unless the maker refused to supply parts or docs. Even Fuji 
had to learn they weren't the only magicians who could repair their 
$7800 tv zoom lenses. Now I'm 83, and still putzing with this stuff, 
with 4 metal carving machines that I converted to be cnc controlled.

I suspect, if we could get Richard to talk, that he too was a nerd before 
the word was invented. Maybe, but he got a later start...

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Richard Owlett]

On 05/11/2018 10:28 AM, Curt wrote:

On 2018-05-11, Richard Owlett  wrote:

On 05/11/2018 08:13 AM, to...@tuxteam.de wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, May 11, 2018 at 07:59:30AM -0500, Richard Owlett wrote:

On 05/06/2018 09:22 AM, Richard Owlett wrote:


[...]


I've been introduced to many commands and some of the "logic" of the
Linux way of doing things.

Thanks everybody.


Thanks for keeping things interesting & fun with your (sometimes
whimsical ;-) enquiries.



I don't recall being whimsical.
Weird. Possibly. Been told that for >70 years ;}



Yeah. And one man's fun and interesting is another man's so narrow and
exiguous a corner case no one but Owlett himself could possibly fit into
it.



*ROFL*  <*MASSIVE GRIN*>
More seriously, the "corner" cases are the valuable ones.
Consider a timing race. Is that not a "corner case". And one that 
requires predictable outcomes.


I spent decades in QA/QC/Engineering Support/Customer Support/... .
Just about everything I dealt with was a "corner case".
It was fun and "EDUCATIONAL" ;/

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Curt]

On 2018-05-11, Richard Owlett  wrote:
> On 05/11/2018 08:13 AM, to...@tuxteam.de wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> On Fri, May 11, 2018 at 07:59:30AM -0500, Richard Owlett wrote:
>>> On 05/06/2018 09:22 AM, Richard Owlett wrote:
>> 
>> [...]
>> 
>>> I've been introduced to many commands and some of the "logic" of the
>>> Linux way of doing things.
>>>
>>> Thanks everybody.
>> 
>> Thanks for keeping things interesting & fun with your (sometimes
>> whimsical ;-) enquiries.
>> 
>
> I don't recall being whimsical.
> Weird. Possibly. Been told that for >70 years ;}
>

Yeah. And one man's fun and interesting is another man's so narrow and
exiguous a corner case no one but Owlett himself could possibly fit into
it.

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[David Wright]

On Fri 11 May 2018 at 07:59:30 (-0500), Richard Owlett wrote:
> On 05/06/2018 09:22 AM, Richard Owlett wrote:
> >I'm attempting to backup current partition  to a USB connected 1 TB drive.
> >
> >I get:
> >
> >>root@debian-jan13:/home/richard# cp -ax / "/media/richard/MISC
> >>backups/dev_sda14/"
> >>cp: cannot stat '/media/richard/MISC 
> >>backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2
> >>problem-2018-02-13/grub2 problem-2018-02-13/grub2
> >>problem-2018-02-13/grub2 problem-2018-02-13/grub2
> >>problem-2018-02-13/grub2 problem-2018-02-13': File name too
> >>long
> >
> 
> The problem turned out to be that
> "local/share/Trash/expunged/73080846/grub2..." appeared under
> *BOTH*
> /home/richard and the root directory.

Evidence of that?

> I successfully ran:
> >root@debian-jan13:/home/richard# updatedb
> >root@debian-jan13:/home/richard# locate TRASH

But   locate TRASH   only searches for TRASH, not Trash. You need to
either   locate -i   or give the appropriate case.

> >root@debian-jan13:/home/richard# cp -ax /  
> >/media/richard/MISC-backups/dev_sda14/
> >root@debian-jan13:/home/richard#

Cheers,
David.

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, May 11, 2018 at 08:22:41AM -0500, Richard Owlett wrote:

[...]

> I don't recall being whimsical.
> Weird. Possibly. Been told that for >70 years ;}

:-)

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr1tFIACgkQBcgs9XrR2kby/gCZARUYmphLpf3T+J2gV2W3ZHMx
f/UAnR9aGLBa6qF4gBl3dRySoRNzuqrB
=Alh/
-END PGP SIGNATURE-

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Pascal Hambourg]

Le 11/05/2018 à 14:59, Richard Owlett a écrit :

On 05/06/2018 09:22 AM, Richard Owlett wrote:
I'm attempting to backup current partition  to a USB connected 1 TB 
drive.


I get:

root@debian-jan13:/home/richard# cp -ax / "/media/richard/MISC 
backups/dev_sda14/"
cp: cannot stat '/media/richard/MISC 
backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13': File name too long




The problem turned out to be that 
"local/share/Trash/expunged/73080846/grub2..." appeared under *BOTH*

/home/richard and the root directory.


Do you mean that there was a

/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13

or

/root/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13

directory ? The former would be really odd. Also, I do not see how 
either would interfere with


/media/richard/MISC 
backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13


or

/home/richard/.local/share/Trash/expunged/73080846/grub2 problem-2018-02-13


I successfully ran:
root@debian-jan13:/home/richard# updatedb
root@debian-jan13:/home/richard# locate TRASH
root@debian-jan13:/home/richard# cp -ax / /media/richard/MISC-backups/dev_sda14/


None of these commands removes any file or directory.

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Richard Owlett]

On 05/11/2018 08:13 AM, to...@tuxteam.de wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, May 11, 2018 at 07:59:30AM -0500, Richard Owlett wrote:

On 05/06/2018 09:22 AM, Richard Owlett wrote:


[...]


I've been introduced to many commands and some of the "logic" of the
Linux way of doing things.

Thanks everybody.


Thanks for keeping things interesting & fun with your (sometimes
whimsical ;-) enquiries.



I don't recall being whimsical.
Weird. Possibly. Been told that for >70 years ;}

Re: SUCCESS!!!! - was {Re: Backup problem using "cp"}

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, May 11, 2018 at 07:59:30AM -0500, Richard Owlett wrote:
> On 05/06/2018 09:22 AM, Richard Owlett wrote:

[...]

> I've been introduced to many commands and some of the "logic" of the
> Linux way of doing things.
> 
> Thanks everybody.

Thanks for keeping things interesting & fun with your (sometimes
whimsical ;-) enquiries. 

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr1lvQACgkQBcgs9XrR2kbH1wCfePOq4h4m8+vfcG43JXdf+G9O
i/wAn2x/Ju6xExwsJFqZkv5VJnFImDRo
=dCCH
-END PGP SIGNATURE-

SUCCESS!!!! - was {Re: Backup problem using "cp"}

[Richard Owlett]

On 05/06/2018 09:22 AM, Richard Owlett wrote:

I'm attempting to backup current partition  to a USB connected 1 TB drive.

I get:

root@debian-jan13:/home/richard# cp -ax / "/media/richard/MISC 
backups/dev_sda14/"
cp: cannot stat '/media/richard/MISC 
backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13': File name too long




The problem turned out to be that 
"local/share/Trash/expunged/73080846/grub2..." appeared under *BOTH*

/home/richard and the root directory.

I successfully ran:

root@debian-jan13:/home/richard# updatedb
root@debian-jan13:/home/richard# locate TRASH
root@debian-jan13:/home/richard# cp -ax /  
/media/richard/MISC-backups/dev_sda14/
root@debian-jan13:/home/richard# 


I've been introduced to many commands and some of the "logic" of the 
Linux way of doing things.


Thanks everybody.

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

[David Wright]

On Wed 09 May 2018 at 22:56:48 (-0400), The Wanderer wrote:
> On 2018-05-09 at 16:20, David Wright wrote:
> 
> > On Tue 08 May 2018 at 22:39:55 (-0400), The Wanderer wrote:
> 
> >> What method are you using to delete it?
> >> 
> >> If you haven't already, I'd recommend trying 'rm -r', *very*
> >> carefully, from a command prompt. (Unless you have an extremely
> >> unusual setup, that should avoid any possibility of an intermediary
> >> "Trash" to need emptying.)
> > 
> > As you're deleting a chain of directories, the appropriate command is
> > rmdir.
> 
> When I initially wrote that, I didn't know that the chain of directories
> didn't contain any non-directory items. (In fact, I'm still not 100%
> certain I do know that, although I think I do.)

Fair enough. But the reason I wanted to use rmdir is precisely because
it will only remove empty directories. Any "real" information that
might happen to be present is protected from loss.

> I also wasn't aware that rmdir could operate recursively; looking now, I
> don't see any indication in its man page that it can. Without that, it
> can only be used to delete one directory at a time, not "a chain of
> directories". Even your own solution handles the "chain" part by using
> find - which admittedly is the canonical default-correct way of doing
> recursive operation in an *nix environment, but also adds a layer of
> complexity not present in a simple 'rm -r'.

Yes, by definition, the directories only become empty (and hence
subject to rmdir) when starting at the bottom. find -depth
solves that.

The problem with using rm -r is that it wipes out any files too.
Also you can't sensibly combine it with -i (beyond the trivial).
So naturally the complexity increases with the care taken.

In summary, those two functions will remove only directories that are
empty, and only prompt for such directories regardless of how deep
they lie.

Cheers,
David.

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

[David Wright]

On Wed 09 May 2018 at 16:32:03 (-0400), Greg Wooledge wrote:
> On Wed, May 09, 2018 at 03:20:06PM -0500, David Wright wrote:
> > remove-empties () 
> > { 
> > [ -z "$1" ] && printf '%s\n' "Usage:$FUNCNAME directories ...
> > removes any empty directories under the directories given after 
> > prompting." 1>&2 && return 1;
> > local IFS="
> > ";
> > find $* -depth -xdev -type d -empty -ok rmdir {} \;
> > }
> 
> $* should be "$@" with the quotes.
> 
> find "$@" -depth -xdev -type d -empty -ok rmdir {} \;

Reviewing my .bashrc, I can see that I had converted 74 occurrences
of $* to "$@" long ago, but 5 had escaped me; I don't know why.

> > (To Greg: is there a better IFS to use?)
> 
> IFS is irrelevant when you quote properly.  You can simply remove that
> assignment command.

OTOH I hadn't bothered to remove their accompanying IFS assignment in
about 50 cases, so I've had a useful tidy up. Probably originated in
some script I copied in the late 20th century. Thanks.

Cheers,
David.

Re: Backup problem using "cp"

[David Wright]

On Thu 10 May 2018 at 09:29:06 (+0100), Jonathan Dowland wrote:
> On Sun, May 06, 2018 at 01:55:32PM -0500, Richard Owlett wrote:
> >I thought I had broken the loop by specifying -x.
> >
> This is one excellent illustration of why cp is the wrong tool for this
> job.

Excellent illustration? You've completely lost me.

Cheers,
David.

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

[Thomas Schmitt]

Hi,

Richard Owlett wrote:
> > I thought I had broken the loop by specifying -x.

Jonathan Dowland wrote: 
> This is one excellent illustration of why cp is the wrong tool for this
> job.

cp -ax is not at fault, as it seems.
The reason for the problem has been identified as a file path on the
original disk which has nearly maximum length and went over the edge
when a 37 byte prefix was added to get a path on the backup disk.

It is yet unclear why the deep tree branch exists on the original disk.
Maybe result of a symbolic link loop and copying with link resolution.
Although i suspect cp to be able to detect link loops. It's not such
an unusual pitfall and the GNU core utilities surely have seen lots
of interesting situations.

So maybe it's the result of a buggy program which wanted to create one
directory with the name "grub2 problem-2018-02-13" and ended up creating
161 of them.


Have a nice day :)

Thomas

Re: Backup problem using "cp"

[Jonathan Dowland]

On Sun, May 06, 2018 at 01:55:32PM -0500, Richard Owlett wrote:

I thought I had broken the loop by specifying -x.


This is one excellent illustration of why cp is the wrong tool for this
job.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

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

[The Wanderer]

On 2018-05-09 at 16:20, David Wright wrote:

> On Tue 08 May 2018 at 22:39:55 (-0400), The Wanderer wrote:

>> What method are you using to delete it?
>> 
>> If you haven't already, I'd recommend trying 'rm -r', *very*
>> carefully, from a command prompt. (Unless you have an extremely
>> unusual setup, that should avoid any possibility of an intermediary
>> "Trash" to need emptying.)
> 
> As you're deleting a chain of directories, the appropriate command is
> rmdir.

When I initially wrote that, I didn't know that the chain of directories
didn't contain any non-directory items. (In fact, I'm still not 100%
certain I do know that, although I think I do.)

I also wasn't aware that rmdir could operate recursively; looking now, I
don't see any indication in its man page that it can. Without that, it
can only be used to delete one directory at a time, not "a chain of
directories". Even your own solution handles the "chain" part by using
find - which admittedly is the canonical default-correct way of doing
recursive operation in an *nix environment, but also adds a layer of
complexity not present in a simple 'rm -r'.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

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

[Greg Wooledge]

On Wed, May 09, 2018 at 03:20:06PM -0500, David Wright wrote:
> remove-empties () 
> { 
> [ -z "$1" ] && printf '%s\n' "Usage:  $FUNCNAME directories ...
>   removes any empty directories under the directories given after 
> prompting." 1>&2 && return 1;
> local IFS="
> ";
> find $* -depth -xdev -type d -empty -ok rmdir {} \;
> }

$* should be "$@" with the quotes.

find "$@" -depth -xdev -type d -empty -ok rmdir {} \;

> (To Greg: is there a better IFS to use?)

IFS is irrelevant when you quote properly.  You can simply remove that
assignment command.

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

[David Wright]

On Tue 08 May 2018 at 22:39:55 (-0400), The Wanderer wrote:
> On 2018-05-08 at 13:48, Richard Owlett wrote:
> 
> > On 05/08/2018 10:38 AM, The Wanderer wrote:
> 
> >> 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:
> 
> Yes, sorry about that - I noticed it after hitting Send.
> 
> >> 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
> 
> Just for the sake of exhaustiveness, can you check the next level down,
> and confirm that it actually does have a different inode?
> 
> >> 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: -
> 
> As David Wright points out, this indicates that this was last modified
> in early March, which should mean that it can't have been deleted in the
> meantime.
> 
> >> 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.
> 
> What method are you using to delete it?
> 
> If you haven't already, I'd recommend trying 'rm -r', *very* carefully,
> from a command prompt. (Unless you have an extremely unusual setup, that
> should avoid any possibility of an intermediary "Trash" to need emptying.)

As you're deleting a chain of directories, the appropriate command is rmdir.

This bash function might prove useful:

remove-empties () 
{ 
[ -z "$1" ] && printf '%s\n' "Usage:$FUNCNAME directories ...
removes any empty directories under the directories given after 
prompting." 1>&2 && return 1;
local IFS="
";
find $* -depth -xdev -type d -empty -ok rmdir {} \;
}

though you could, for now, just cut and paste this line:

find /home/richard/.local/share/Trash/expunged/1449727740/ -depth -xdev -type d 
-empty -ok rmdir {} \;

Having to type y 161 times might serve as punishment :)

Alternatively, there's this function:

remove-empties-unprompted () 
{ 
[ -z "$1" ] && printf '%s\n' "Usage:$FUNCNAME directories ...
removes any empty directories under the directories given WITHOUT 
prompting." 1>&2 && return 1;
local IFS="
";
find $* -depth -xdev -type d -empty -print -exec rmdir {} \;
}

which does the job more quickly. Remove the "-print" if you want it
done silently too.

(To Greg: is there a better IFS to use?)

Cheers,
David.

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

[Thomas Schmitt]

Hi,

Richard Owlett wrote:
> > /home/richard/.local/share/Trash/expunged/1449727740/
> └── grub2 problem-2018-02-13
> ...
> Goes on for 161 directories

The name is 24 bytes long.
Plus one slash yields 25.
161 times 25 = 4025 bytes for the problem directories.
Plus 53 for "/home/...40/" = 4078.
So far your system accepted the path.

But plus 37 for "/media/richard/...sda14" yields 4115 and caused protest.

Google finds me
  https://github.com/torvalds/linux/blob/master/include/uapi/linux/limits.h
saying
  #define PATH_MAX 4096 /* # chars in a path name including nul */
My local
  /usr/include/linux/limits.h
says the same.

So Linux publishes a limit of at most 4095 bytes for paths.
Many filesystem will actually have this limit or lower ones. It is not
clear whether you bonked against a fixed limit of Linux or a specific
limit of the particular filesystem on the USB disk.

The origin of this insane directory chain is obscure, of course. Maybe
the name parts "grub2" and "2018-02-13" help Richard to remember what
might have happened back then.

For the purpose of disk sanity (and maybe successful "cp -ax") i'd then
consider to remove these directories.


Congrats:
David Wright made the better initial guess, compared to mine.

-

> I suspect some of my confusion revolves around not understanding "2>&1".

That's about
- "standard output" (result channel of classical Unix programs
- "standard error" (non-result message channel)
- "redirection" (plugging together such channels)
- "file descriptors" (a programmer's thing, actually) which get set at
  program start to:
0 = standard input (the channel for input text, normally your keyboard)
1 = standard output (normally your terminal)
2 = standard error (normally your terminal, too)

All together "2>&1" funnels the non-result messages of a program into the
result channel. This is done typically before a pipe that consumes standard
output

  program 2>&1 | other_program

or _after_ a redirection of standard output to a file

  program >log_file 2>&1 

In both cases it shall join both output channels into a single channel.

(If you write "program 2>&1 >log_file" the non-result messages will
 appear on the former standard output and the results will go into the
 file "log_file". Sequence matters.)


Have a nice day :)

Thomas

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

[Richard Hector]

On 10/05/18 00:28, Richard Owlett wrote:

>> /home/richard/.local/share/Trash/expunged/1449727740/
>> └── grub2 problem-2018-02-13
>>     └── grub2 problem-2018-02-13
>>     └── grub2 problem-2018-02-13
>>     └── grub2 problem-2018-02-13
>>     └── grub2 problem-2018-02-13
>>     └── grub2 problem-2018-02-13
>>     └── grub2 problem-2018-02-13
>>     └── grub2 problem-2018-02-13
> 
> Goes on for 161 directories

161 'grub2 problem-2018-02-13' directories? That makes sense; if you
added one more you'd go over the 4016-character (byte?) path length limit.

I'm intrigued as to how cp can create directories in the source tree though.

Are there symlinks involved?

Does

find /home/richard/.local/share/Trash/expunged/1449727740 -type l

show up anything useful?

If the new tree ends up linking back into the old one, for instance, it
could get interesting. (my quick tests suggest not that interesting,
actually, but I might not be testing the right scenario)

Richard



signature.asc
Description: OpenPGP digital signature

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

[The Wanderer]

On 2018-05-09 at 08:28, Richard Owlett wrote:

> On 05/08/2018 09:39 PM, The Wanderer wrote:

>> If you haven't already, I'd recommend trying 'rm -r', *very*
>> carefully, from a command prompt. (Unless you have an extremely
>> unusual setup, that should avoid any possibility of an intermediary
>> "Trash" to need emptying.)
>> 
>> Do you have mlocate installed on your system? If so, the output of
>> 
>> locate 'grub2 problem-2018-02-13'



>> might be informative; if it finds a copy of the directory
>> somewhere else, that might tell us where it's being restored from,
>> if it is indeed being restored.
> 
> I'll try this afternoon or tomorrow. I'll read documentation for "rm"
> first and use it to purge what I know I'm not interested in. Then
> re-run "locate". I'll wait until I know that I don't have to preserve
> the machine' current state.

Note that 'locate' doesn't update instantly; it draws from an index,
which is normally updated by a cron job, on a nightly basis or so.

If you want it to update its index right away without waiting, you need
to run 'updatedb'. IIRC that might need to be done as root (or with
similar levels of access to /var/lib/mlocate/mlocate.db), though I
haven't checked lately.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

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

[Richard Owlett]

On 05/08/2018 09:39 PM, The Wanderer wrote:

On 2018-05-08 at 13:48, Richard Owlett wrote:
[massive SNIP]
What method are you using to delete it?


Moving directory to trash and then emptying the trash with MATE's 
graphical tools.




If you haven't already, I'd recommend trying 'rm -r', *very* carefully,
from a command prompt. (Unless you have an extremely unusual setup, that
should avoid any possibility of an intermediary "Trash" to need emptying.)

Do you have mlocate installed on your system? If so, the output of

locate 'grub2 problem-2018-02-13'


It starts off with:

/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13



/home/richard/.local/share/Trash/expunged/1449727740/grub2 
problem-2018-02-13/grub2 problem-2018-02-13



/home/richard/.local/share/Trash/expunged/1449727740/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13



/home/richard/.local/share/Trash/expunged/1449727740/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13

and goes on for >100 kB.

Running
  /home/richard# tree -adRA -L 8 
/home/richard/.local/share/Trash/expunged/1449727740/

gives:>

/home/richard/.local/share/Trash/expunged/1449727740/
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13


Goes on for 161 directories



might be informative; if it finds a copy of the directory somewhere
else, that might tell us where it's being restored from, if it is indeed
being restored.



I'll try this afternoon or tomorrow. I'll read documentation for "rm" 
first and use it to purge what I know I'm not interested in. Then re-run 
"locate". I'll wait until I know that I don't have to preserve the 
machine' current state.


Thanks

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

[Richard Owlett]

On 05/08/2018 03:22 PM, Thomas Schmitt wrote:

Hi,

Richard Owlett wrote:

I couldn't interpret what I was seeing so below are excerpts of what was
captured by script command.


It is hard to understand what "script" wants to tell us.
"less" would have been more useful for our purpose of displaying output
and navigating in it.



I couldn't figure out how to post a useful segment. I suspect some of my 
confusion revolves around not understanding "2>&1".




[snip]


We need to apply clear classic commands:

   cd /home/richard/.local/share/Trash/expunged/1449727740

   find . -exec ls -ld '{}' ';' >/tmp/weird_tree.txt 2>&1

This will create a file named /tmp/weird_tree.txt with the output of
"ls -ld" of each file underneath "1449727740".

Please upload this file somewhere, so that its lines do not get hacked
into pieces or abbreviated. Or send it as attachment to my mail address.


I have run that if you need it.
I think I have a more compact view of that information.
I ran:
  tree -adRA -L 8 /home/richard/.local/share/Trash/expunged/1449727740/
The output was:


/home/richard/.local/share/Trash/expunged/1449727740/
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13
└── grub2 problem-2018-02-13


Goes on for 161 directories

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

[The Wanderer]

On 2018-05-08 at 13:48, Richard Owlett wrote:

> On 05/08/2018 10:38 AM, The Wanderer wrote:

>> 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:

Yes, sorry about that - I noticed it after hitting Send.

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

Just for the sake of exhaustiveness, can you check the next level down,
and confirm that it actually does have a different inode?

>> 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: -

As David Wright points out, this indicates that this was last modified
in early March, which should mean that it can't have been deleted in the
meantime.

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

What method are you using to delete it?

If you haven't already, I'd recommend trying 'rm -r', *very* carefully,
from a command prompt. (Unless you have an extremely unusual setup, that
should avoid any possibility of an intermediary "Trash" to need emptying.)

Do you have mlocate installed on your system? If so, the output of

locate 'grub2 problem-2018-02-13'

might be informative; if it finds a copy of the directory somewhere
else, that might tell us where it's being restored from, if it is indeed
being restored.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

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

[Thomas Schmitt]

Hi,

Richard Owlett wrote:
> I couldn't interpret what I was seeing so below are excerpts of what was
> captured by script command.

It is hard to understand what "script" wants to tell us.
"less" would have been more useful for our purpose of displaying output
and navigating in it.


Whatever, we see a strange directory branch:
> /home/richard/.local/share/Trash/expunged/1449727740/grub2
> problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2
> problem-2018-02-13/grub2 problem-2018-02-13: 

Whether it goes deeper is not clear. Your original message had:

> > cp: cannot stat '/media/richard/MISC
> > backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2
> > problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2
> > problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13':
> > File name too long

That's at least 6 of the "grub2 problem-2018-02-13", not five as in your
"script" text. 

We need to apply clear classic commands:

  cd /home/richard/.local/share/Trash/expunged/1449727740

  find . -exec ls -ld '{}' ';' >/tmp/weird_tree.txt 2>&1

This will create a file named /tmp/weird_tree.txt with the output of
"ls -ld" of each file underneath "1449727740".

Please upload this file somewhere, so that its lines do not get hacked
into pieces or abbreviated. Or send it as attachment to my mail address.


Have a nice day :)

Thomas

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

[David Wright]

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

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

[Richard Owlett]

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:




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: 4096Blocks: 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 ;/

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

[Richard Owlett]

On 05/08/2018 10:38 AM, Thomas Schmitt wrote:

[snip]

Something could be wrong with the input tree instead. Especially around file
"grub2 problem-2018-02-13".

What do you get from

   ls -lR /home/richard/.local/share/Trash/expunged/1449727740/"grub2 
problem-2018-02-13" 2>&1 | less

This could be many text lines. So i propose to pipe the output into "less"
and to then explore it without flooding the terminal.

If nothing spectacular shows up: What does this yield:
 > Script started on Tue 08 May 2018 12:03:45 PM CDT
root@debian-jan13:/home/richard# # What do you get from
root@debian-jan13:/home/richard# ##  ls -lR /home/richard/.local/share/Trash/expunged/1449727740/"grub2 
 problem-2018-02-13" 2>&1
root@debian-jan13:/home/richard# 
root@debian-jan13:/home/richard# ls -lR /home/richard/.local/share/Trash/expunged/1449727740/"grub2 prob

blem-2018-02-13" 2>&1
/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13: 

 Insert visual break 



total 4
drwx-- 3 richard richard 4096 Mar  6 09:41 grub2 problem-2018-02-13

/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13/grub2 problem-2018-02-13: 

 Insert visual break 



total 4
drwx-- 3 richard richard 4096 Mar  6 09:41 grub2 problem-2018-02-13

/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13: 

 Insert visual break 



total 4
drwx-- 3 richard richard 4096 Mar  6 09:41 grub2 problem-2018-02-13

/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13: 

 Insert visual break 



total 4
drwx-- 3 richard richard 4096 Mar  6 09:41 grub2 problem-2018-02-13

/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13: 

 Insert visual break 


root@debian-jan13:/home/richard# # If nothing spectacular shows up: 
What does this yield:
root@debian-jan13:/home/richard# ##ls -lR 
/home/richard/.local/share/Trash/expunged/1449727740 2>&1
root@debian-jan13:/home/richard# 
root@debian-jan13:/home/richard# ls -lR /home/richard/.local/share/Trash/expunged/1449727740 2>&1

/home/richard/.local/share/Trash/expunged/1449727740:
total 4
drwx-- 3 richard richard 4096 Mar  6 09:41 grub2 problem-2018-02-13

/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13: 

 Insert visual break 



total 4
drwx-- 3 richard richard 4096 Mar  6 09:41 grub2 problem-2018-02-13

/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13/grub2 problem-2018-02-13: 

 Insert visual break 



total 4
drwx-- 3 richard richard 4096 Mar  6 09:41 grub2 problem-2018-02-13

/home/richard/.local/share/Trash/expunged/1449727740/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13: 

 Insert visual break 



root@debian-jan13:/home/richard# 
root@debian-jan13:/home/richard# # exit script command

root@debian-jan13:/home/richard# exit
exit

Script done on Tue 08 May 2018 12:08:04 PM CDT




   ls -lR /home/richard/.local/share/Trash/expunged/1449727740 2>&1 | less




I couldn't interpret what I was seeing so below are excerpts of what was 
captured by script command.

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

[The Wanderer]

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:



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.

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.

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

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

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

[Thomas Schmitt]

Hi,

Richard Owlett wrote:
> # stat / | fgrep Device
> Device: 80eh/2062dInode: 2   Links: 22
> ...
> # stat /media/richard/MISC-backups/dev_sda14/ | fgrep Device
> Device: 819h/2073dInode: 15728641Links: 4

That's different filesystems.
So cp -x should not try to copy again what it just had copied.


> cp: cannot stat
> '/media/richard/MISC-backups/dev_sda14/home/richard/.local/share/Trash/exp
> unged/1449727740/grub2 problem-2018-02-13/grub2 problem-2018-02-13/...
> ... ...
> ... grub2 problem-2018-02-13': File name too long

It seems that my theory is not valid.

Something could be wrong with the input tree instead. Especially around file
"grub2 problem-2018-02-13".

What do you get from

  ls -lR /home/richard/.local/share/Trash/expunged/1449727740/"grub2 
problem-2018-02-13" 2>&1 | less

This could be many text lines. So i propose to pipe the output into "less"
and to then explore it without flooding the terminal.

If nothing spectacular shows up: What does this yield:

  ls -lR /home/richard/.local/share/Trash/expunged/1449727740 2>&1 | less


Have a nice day :)

Thomas

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

[Richard Owlett]

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:






Script started, file is typescript



#



#



rm -rv /media/root/MISC-backups/



#



#



ls /media/richard/MISC-backups/dev_sda14/



#



#



stat / | fgrep Device



#



#



stat /media | fgrep Device



#



#



stat /media/richard/MISC-backups/dev_sda14/ | fgrep Device



#



#



cp -ax /  /media/richard/MISC-backups/dev_sda14/



#



#



ls /media/richard/MISC-backups/dev_sda14/



#



#



ls /media/richard/MISC-backups/dev_sda14/*



#



#



ls /media/richard/MISC-backups/dev_sda14/home/richard



#



#



ls -aRil /media/richard/MISC-backups/dev_sda14/



#



#



exit



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# rm -rv /media/root/MISC-backups/



rm: cannot remove '/media/root/MISC-backups/': No such file or directory



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# ls /media/richard/MISC-backups/dev_sda14/



home  lost+found



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# stat / | fgrep Device



Device: 80eh/2062d  Inode: 2   Links: 22



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# stat /media | fgrep Device



Device: 80eh/2062d  Inode: 131073  Links: 5



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# stat /media/richard/MISC-backups/dev_sda14/ | 
fgrep Device



Device: 819h/2073d  Inode: 15728641Links: 4



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# cp -ax /  
/media/richard/MISC-backups/dev_sda14/







cp: cannot stat 
'/media/richard/MISC-backups/dev_sda14/home/richard/.local/share/Trash/expunged/1449727740/grub2
 problem-2018-02-13/grub2 problem-2018-02-13/...
... 
...

... grub2 problem-2018-02-13': File name too long



^C


root@debian-jan13:/home/richard# 



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# ls /media/richard/MISC-backups/dev_sda14/



home  lost+found



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# ls /media/richard/MISC-backups/dev_sda14/*



/media/richard/MISC-backups/dev_sda14/home:



richard







/media/richard/MISC-backups/dev_sda14/lost+found:



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# ls 
/media/richard/MISC-backups/dev_sda14/home/richard



Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos



root@debian-jan13:/home/richard# #



root@debian-jan13:/home/richard# #


I also have the output of
  ls -aRil /media/richard/MISC-backups/dev_sda14/
available. IIRC someone had requested I run a similar command.
TIA

Re: Backup problem using "cp"

[David Wright]

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

Re: Backup problem using "cp"

[David Wright]

On Mon 07 May 2018 at 15:28:14 (+0200), Thomas Schmitt wrote:
> Hi,
> 
> Richard Owlett wrote:
> > My goal was to copy root and its sub-directory to a directory on another
> > physical device.
> 
> Well understood.
> In a slightly different scenario (backup on Blu-ray) i do this several
> times per day.
> 
> But i would not dare to give the whole root tree as input to any copying
> program or backup archiver.

I've cloned live systems in the past by writing:

# cd /
# find -xdev -path './lost+found' -prune -o -print | cpio -vdamp /mnt

(omitting v to make it quieter).

> Not only because of the risk of stepping on my
> own foot but also because there are several trees which do not deserve
> backup or could even make trouble when being fully read.
> 
> In my root directory that would be: /dev /mnt /proc /run /sys
> E.g. because of
>   $ ls -l /proc/kcore
>   -r 1 root root 140737477877760 May  7 15:22 /proc/kcore
> 
> (Somebody else shall try whether it's really readable and what comes out.
>  The announced size is nearly 128 TiB.)

The -xdev (or cp -x) deals with those.

Cheers,
David.

Re: Backup problem using "cp"

[David Wright]

On Mon 07 May 2018 at 06:31:16 (-0500), Richard Owlett wrote:
> On 05/06/2018 10:11 AM, Thomas Schmitt wrote:
> >Hi,
> >
> >Richard Owlett wrote:
> >>Thought I was doing that by specifying -x.
> >
> >Either cp -x has a bug or the target directory is not in a different
> >filesystem than "/" and not a mount point of such a filesystem.
> >
> >Check the device numbers of "/" and "/media/richard/MISC...".
> >E.g. like this
> >
> >   $ stat / | fgrep Device
> >   Device: 803h/2051d  Inode: 2   Links: 25
> >   $ stat /bkp | fgrep Device
> >   Device: 814h/2068d  Inode: 2   Links: 7
> >
> >Here "/bkp" has a different device number (2068) than "/" (2051).
> >So it (its inode, to be exacting) is in a different filesystem.
> >
> >As contrast see a directory in the same filesystem as "/":
> >
> >   $ stat /home | fgrep Device
> >   Device: 803h/2051d  Inode: 2228225 Links: 60
> 
> I get:
> richard@debian-jan13:~$ stat / | fgrep Device
> Device: 80eh/2062dInode: 2   Links: 22
> richard@debian-jan13:~$ stat /media | fgrep Device
> Device: 80eh/2062dInode: 131073  Links: 5
> richard@debian-jan13:~$
> 
> I gather that "cp" is then an inappropriate tool.
> 
> "tar" is inappropriate for my preferences - I was attempting to use
> "cp" as there would be multiple files &/or directories as input
> *and* output.

If you have multiple outputs, I'm intrigued to know how you automate
the decision between writing to one output or another.

> I suspect long term I want "rsync" [ *MUCH* reading to do! ]
> 
> 
> >>Any way to accomplish that without explicitly listing all directories except
> >>/media ?
> >
> >If it is indeed a bug with cp -x, then you could use some archiver like
> >"tar" which has options to exclude a file.
> > > Get inspiration from googling "tar pipe for copying".
> 
> Although I wish to avoid "tar", I did get inspiration for a brute
> force method - I'll try it first before commenting.

I'm interested to know, if you have a file with a pathname that's,
say, 4090 characters long, how that gets written to a directory
whose name is more than half a dozen characters. IOW how does
tar succeed where cp failed?

Cheers,
David.

Re: Backup problem using "cp"

[Charlie Gibbs]

On 07/05/18 04:31 AM, Richard Owlett wrote:


I gather that "cp" is then an inappropriate tool.

"tar" is inappropriate for my preferences - I was attempting to use "cp"
as there would be multiple files &/or directories as input *and* output.

I suspect long term I want "rsync" [ *MUCH* reading to do! ]


I went way too long before switching to rsync.  I always thought that 
the command-line parameters were too complex (the man page _does_ get a 
bit intimidating).  However, I've come up with a standard that works 
well enough to tide me over until I really study it:


rsync -avzh --delete -n  

Note the -n parameter; it causes rsync to go through the motions but not 
actually do anything.  You'll get a complete list of what it would have 
done on stdout, followed by the message "DRY RUN".  Once you're happy 
with what you see, repeat the command without the -n and away you go. 
(The --delete parameter tells rsync to delete any file in the output 
directory that isn't in the input directory; you may or may not want this.)


Someday in my copious free time (hah!) I'll study how to tell it not to 
back up those hundreds of browser cache files when backing up /home. 
But for now it works well enough, and is still much faster than cp.


--
cgi...@surfnaked.ca (Charlie Gibbs)

Re: Backup problem using "cp"

[Jude DaShiell]

On Mon, 7 May 2018, Kushal Kumaran wrote:


Date: Mon, 7 May 2018 13:15:48
From: Kushal Kumaran 
To: debian-user@lists.debian.org
Subject: Re: Backup problem using "cp"
Resent-Date: Mon,  7 May 2018 17:16:09 + (UTC)
Resent-From: debian-user@lists.debian.org

Richard Owlett  writes:


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


No the _apparent_ line break was an artifact of email quoting process.
I can't rerun the diagnostic at the moment - hardware fully occupied
with testing my proposed workaround, which works so far but progress
resembles molasses running uphill on Pluto in winter ;/






I gather that "cp" is then an inappropriate tool.


That's not decided yet.

If your cp target directory had a different device number, then cp option -x
did not what it is supposed to do.

But if your target directory was not the mount point of the USB disk and
not inside the filesystem of the USB disk, then you made a mistake by
giving that directory as target.


Understood.





"tar" is inappropriate for my preferences - I was attempting to use "cp" as
there would be multiple files &/or directories as input *and* output.


You could use multiple tar commands.
(I doubt that you can talk cp into addressing more than one target.)


Communication confusion.
My goal was to copy root and its sub-directory to a directory on
another physical device.



Are you using an LVM volume as your root?  Then mounting a snapshot at
some location and copying from there is a good option.  This is what I
do for my own backups.

If you're not using LVM volumes, you could still use bind mounts for
this.  Run:

 # mkdir -p /mnt/source
 # mount --bind -o ro / /mnt/source

(The -o ro option is to make the /mnt/source mount read only.  I
understand you intend to use this as a backup source, so read-only
access should be sufficient.  If you change it to not be read-only, be
cautious when changing things in /mnt/source, because it is the same
filesystem as /)

Now /mnt/source is exactly the root filesystem.  Other filesystems
mounted (such as /dev or /proc) would only be present as empty
directories in /mnt/source.  After you're done copying, remove the bind
by running:

 # umount /mnt/source

This way, you do not have to figure out an exclude list or instruct
tools to stop at filesystem boundaries.

Make sure you do verify the files and directories you need are included.
If some of the required files are not part of the root filesystem, then
bind-mount them at the proper location under /mnt/source as well.  For
example, if your /home is a different filesystem, and you need it to be
part of your copying:

 # mkdir -p /mnt/source
 # mount --bind -o ro / /mnt/source
 # mount --bind -o ro /home /mnt/source/home

Then unmounting after you finish copying will be in the reverse order:

 # umount /mnt/source/home
 # umount /mnt/source

Tar has a -T file and an -X file set of options too.  Of course files 
with includes and excludes will have to exist before the copying for that 
to work.






--

Re: Backup problem using "cp"

[Kushal Kumaran]

Richard Owlett  writes:

> 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.)
>
> No the _apparent_ line break was an artifact of email quoting process.
> I can't rerun the diagnostic at the moment - hardware fully occupied
> with testing my proposed workaround, which works so far but progress
> resembles molasses running uphill on Pluto in winter ;/
>
>
>>
>>
>>> I gather that "cp" is then an inappropriate tool.
>>
>> That's not decided yet.
>>
>> If your cp target directory had a different device number, then cp option -x
>> did not what it is supposed to do.
>>
>> But if your target directory was not the mount point of the USB disk and
>> not inside the filesystem of the USB disk, then you made a mistake by
>> giving that directory as target.
>
> Understood.
>
>>
>>
>>> "tar" is inappropriate for my preferences - I was attempting to use "cp" as
>>> there would be multiple files &/or directories as input *and* output.
>>
>> You could use multiple tar commands.
>> (I doubt that you can talk cp into addressing more than one target.)
>
> Communication confusion.
> My goal was to copy root and its sub-directory to a directory on
> another physical device.
>

Are you using an LVM volume as your root?  Then mounting a snapshot at
some location and copying from there is a good option.  This is what I
do for my own backups.

If you're not using LVM volumes, you could still use bind mounts for
this.  Run:

  # mkdir -p /mnt/source
  # mount --bind -o ro / /mnt/source

(The -o ro option is to make the /mnt/source mount read only.  I
understand you intend to use this as a backup source, so read-only
access should be sufficient.  If you change it to not be read-only, be
cautious when changing things in /mnt/source, because it is the same
filesystem as /)

Now /mnt/source is exactly the root filesystem.  Other filesystems
mounted (such as /dev or /proc) would only be present as empty
directories in /mnt/source.  After you're done copying, remove the bind
by running:

  # umount /mnt/source

This way, you do not have to figure out an exclude list or instruct
tools to stop at filesystem boundaries.

Make sure you do verify the files and directories you need are included.
If some of the required files are not part of the root filesystem, then
bind-mount them at the proper location under /mnt/source as well.  For
example, if your /home is a different filesystem, and you need it to be
part of your copying:

  # mkdir -p /mnt/source
  # mount --bind -o ro / /mnt/source
  # mount --bind -o ro /home /mnt/source/home

Then unmounting after you finish copying will be in the reverse order:

  # umount /mnt/source/home
  # umount /mnt/source

-- 
regards,
kushal

Re: Backup problem using "cp"

[Dan Norton]

On Mon, 7 May 2018 09:59:01 -0400
Bob Weber  wrote:

> On 5/7/18 9:28 AM, Thomas Schmitt wrote:
> > Hi,
> >
> > Richard Owlett wrote:  
> >> My goal was to copy root and its sub-directory to a directory on
> >> another physical device.  
> > Well understood.
> > In a slightly different scenario (backup on Blu-ray) i do this
> > several times per day.
> >
> > But i would not dare to give the whole root tree as input to any
> > copying program or backup archiver. Not only because of the risk of
> > stepping on my own foot but also because there are several trees
> > which do not deserve backup or could even make trouble when being
> > fully read.
> >
> > In my root directory that would be: /dev /mnt /proc /run /sys
> > E.g. because of
> >$ ls -l /proc/kcore
> >-r 1 root root 140737477877760 May  7 15:22 /proc/kcore
> >
> > (Somebody else shall try whether it's really readable and what
> > comes out. The announced size is nearly 128 TiB.)
> >
> >
> > Have a nice day :)
> >
> > Thomas
> >
> >  
> There is a program called rsnapshot that uses rsync for the actual
> work of copying but has a config file where you can supply exclude
> directories (like /media).  I just run "rsnapshot hourly" to copy my
> root file system before an apt upgrade command just in case a major
> problem occurs with the update.  The /proc /sys and /dev directories
> are not copied since they are "mounted" system directories.
> rsnapshot uses hard links between backups so only the changed files
> are actually copied.  The number of versions to keep is configured
> in /etc/rsnapshot.conf.
> 
> In using your cp command, rsync or rsnapshot it is very important
> that the destination filesystem be able to handle hard links and all
> the file attributes of a linux file system.  So make sure that at
> least there is an ext3 or ext4 type file system on the destination
> drive.  If you are not sure what file system is in use for the backup
> destination just run the mount command (as root) without any
> arguments and it will print out all the mounted file systems and
> types.

Another way to show fs type, without showing so much system stuff:

$ lsblk -f

This also shows labels (if any) and mount points.

 - Dan

Re: Backup problem using "cp"

[Richard Owlett]

On 05/07/2018 08:54 AM, Richard Hector wrote:

On 08/05/18 00:55, David Griffith wrote:

On May 7, 2018 4:31:16 AM PDT, Richard Owlett  wrote:

On 05/06/2018 10:11 AM, Thomas Schmitt wrote:

Hi,

Richard Owlett wrote:

Thought I was doing that by specifying -x.


Either cp -x has a bug or the target directory is not in a different
filesystem than "/" and not a mount point of such a filesystem.

Check the device numbers of "/" and "/media/richard/MISC...".
E.g. like this

$ stat / | fgrep Device
Device: 803h/2051d  Inode: 2   Links: 25
$ stat /bkp | fgrep Device
Device: 814h/2068d  Inode: 2   Links: 7

Here "/bkp" has a different device number (2068) than "/" (2051).
So it (its inode, to be exacting) is in a different filesystem.

As contrast see a directory in the same filesystem as "/":

$ stat /home | fgrep Device
Device: 803h/2051d  Inode: 2228225 Links: 60


I get:
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
richard@debian-jan13:~$

I gather that "cp" is then an inappropriate tool.

"tar" is inappropriate for my preferences - I was attempting to use
"cp"
as there would be multiple files &/or directories as input *and*
output.

I suspect long term I want "rsync" [ *MUCH* reading to do! ]



You will indeed want rsync.  Essentially, "rsync -av [--delete]  
 will serve most of your backup needs.



I habitually include -x in there as well, which I suspect will be needed
here.

And for my uses, I always make sure there are trailing slashes on both
source and destination.



My last run was:
 cp -ax / "/media/richard/MISC backups/dev_sda14/"

Re: Backup problem using "cp"

[Richard Owlett]

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-2018-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. 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...". '

Re: Backup problem using "cp"

[Richard Owlett]

On 05/07/2018 08:24 AM, Andy Smith wrote:

Hello,

On Mon, May 07, 2018 at 07:51:23AM -0500, Richard Owlett wrote:

I'll likely abandon further immediate investigation of cp. I've other
projects to complete 


It would still be good to establish why "cp -x" was seemingly able
to cross filesystem boundaries as that would be a bug.



Agreed. That's why I said "immediate investigation".

Re: Backup problem using "cp"

[Richard Owlett]

On 05/07/2018 08:28 AM, Thomas Schmitt wrote:

Hi,

Richard Owlett wrote:

My goal was to copy root and its sub-directory to a directory on another
physical device.


Well understood.
In a slightly different scenario (backup on Blu-ray) i do this several
times per day.

But i would not dare to give the whole root tree as input to any copying
program or backup archiver. Not only because of the risk of stepping on my
own foot but also because there are several trees which do not deserve
backup or could even make trouble when being fully read.

In my root directory that would be: /dev /mnt /proc /run /sys


For my purposes I would add /media .

Re: Backup problem using "cp"

[Bob Weber]

On 5/7/18 9:28 AM, Thomas Schmitt wrote:

Hi,

Richard Owlett wrote:

My goal was to copy root and its sub-directory to a directory on another
physical device.

Well understood.
In a slightly different scenario (backup on Blu-ray) i do this several
times per day.

But i would not dare to give the whole root tree as input to any copying
program or backup archiver. Not only because of the risk of stepping on my
own foot but also because there are several trees which do not deserve
backup or could even make trouble when being fully read.

In my root directory that would be: /dev /mnt /proc /run /sys
E.g. because of
   $ ls -l /proc/kcore
   -r 1 root root 140737477877760 May  7 15:22 /proc/kcore

(Somebody else shall try whether it's really readable and what comes out.
  The announced size is nearly 128 TiB.)


Have a nice day :)

Thomas


There is a program called rsnapshot that uses rsync for the actual work of 
copying but has a config file where you can supply exclude directories (like 
/media).  I just run "rsnapshot hourly" to copy my root file system before an 
apt upgrade command just in case a major problem occurs with the update.  The 
/proc /sys and /dev directories are not copied since they are "mounted" system 
directories.  rsnapshot uses hard links between backups so only the changed 
files are actually copied.  The number of versions to keep is configured in 
/etc/rsnapshot.conf.


In using your cp command, rsync or rsnapshot it is very important that the 
destination filesystem be able to handle hard links and all the file attributes 
of a linux file system.  So make sure that at least there is an ext3 or ext4 
type file system on the destination drive.  If you are not sure what file system 
is in use for the backup destination just run the mount command (as root) 
without any arguments and it will print out all the mounted file systems and 
types.  I get this line for my /home directory:


/dev/md2 on /home type ext4 (rw,relatime,data=ordered)

If I plug in a flash drive and have the system mount it I get (all one line):

/dev/sdg1 on /media/bob/3A78-573B type vfat 
(rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)


Notice the type vfat which is NOT what you want to see on the destination file 
system.


--


*...Bob*

Re: Backup problem using "cp"

[Richard Hector]

On 08/05/18 00:55, David Griffith wrote:
> On May 7, 2018 4:31:16 AM PDT, Richard Owlett  wrote:
>> On 05/06/2018 10:11 AM, Thomas Schmitt wrote:
>>> Hi,
>>>
>>> Richard Owlett wrote:
 Thought I was doing that by specifying -x.
>>>
>>> Either cp -x has a bug or the target directory is not in a different
>>> filesystem than "/" and not a mount point of such a filesystem.
>>>
>>> Check the device numbers of "/" and "/media/richard/MISC...".
>>> E.g. like this
>>>
>>>$ stat / | fgrep Device
>>>Device: 803h/2051d  Inode: 2   Links: 25
>>>$ stat /bkp | fgrep Device
>>>Device: 814h/2068d  Inode: 2   Links: 7
>>>
>>> Here "/bkp" has a different device number (2068) than "/" (2051).
>>> So it (its inode, to be exacting) is in a different filesystem.
>>>
>>> As contrast see a directory in the same filesystem as "/":
>>>
>>>$ stat /home | fgrep Device
>>>Device: 803h/2051d  Inode: 2228225 Links: 60
>>
>> I get:
>> 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
>> richard@debian-jan13:~$
>>
>> I gather that "cp" is then an inappropriate tool.
>>
>> "tar" is inappropriate for my preferences - I was attempting to use
>> "cp" 
>> as there would be multiple files &/or directories as input *and*
>> output.
>>
>> I suspect long term I want "rsync" [ *MUCH* reading to do! ]
> 
> 
> You will indeed want rsync.  Essentially, "rsync -av [--delete]  
>  will serve most of your backup needs.
> 

I habitually include -x in there as well, which I suspect will be needed
here.

And for my uses, I always make sure there are trailing slashes on both
source and destination.

Richard




signature.asc
Description: OpenPGP digital signature

Re: Backup problem using "cp"

[Thomas Schmitt]

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


Have a nice day :)

Thomas

Re: Backup problem using "cp"

[Richard Owlett]

On 05/07/2018 07:55 AM, David Griffith wrote:

On May 7, 2018 4:31:16 AM PDT, Richard Owlett  wrote:

On 05/06/2018 10:11 AM, Thomas Schmitt wrote:

Hi,

Richard Owlett wrote:

Thought I was doing that by specifying -x.


Either cp -x has a bug or the target directory is not in a different
filesystem than "/" and not a mount point of such a filesystem.

Check the device numbers of "/" and "/media/richard/MISC...".
E.g. like this

$ stat / | fgrep Device
Device: 803h/2051d  Inode: 2   Links: 25
$ stat /bkp | fgrep Device
Device: 814h/2068d  Inode: 2   Links: 7

Here "/bkp" has a different device number (2068) than "/" (2051).
So it (its inode, to be exacting) is in a different filesystem.

As contrast see a directory in the same filesystem as "/":

$ stat /home | fgrep Device
Device: 803h/2051d  Inode: 2228225 Links: 60


I get:
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
richard@debian-jan13:~$

I gather that "cp" is then an inappropriate tool.

"tar" is inappropriate for my preferences - I was attempting to use
"cp"
as there would be multiple files &/or directories as input *and*
output.

I suspect long term I want "rsync" [ *MUCH* reading to do! ]



You will indeed want rsync.  Essentially, "rsync -av [--delete]  
 will serve most of your backup needs.



I have an explicit need for --exclude. Man page terminally terse ;/
So far the tutorials I've found try to show off the super powers of 
rsync to power users :{

Re: Backup problem using "cp"

[Thomas Schmitt]

Hi,

Richard Owlett wrote:
> My goal was to copy root and its sub-directory to a directory on another
> physical device.

Well understood.
In a slightly different scenario (backup on Blu-ray) i do this several
times per day.

But i would not dare to give the whole root tree as input to any copying
program or backup archiver. Not only because of the risk of stepping on my
own foot but also because there are several trees which do not deserve
backup or could even make trouble when being fully read.

In my root directory that would be: /dev /mnt /proc /run /sys
E.g. because of
  $ ls -l /proc/kcore
  -r 1 root root 140737477877760 May  7 15:22 /proc/kcore

(Somebody else shall try whether it's really readable and what comes out.
 The announced size is nearly 128 TiB.)


Have a nice day :)

Thomas

Re: Backup problem using "cp"

[Andy Smith]

Hello,

On Mon, May 07, 2018 at 07:51:23AM -0500, Richard Owlett wrote:
> I'll likely abandon further immediate investigation of cp. I've other
> projects to complete 

It would still be good to establish why "cp -x" was seemingly able
to cross filesystem boundaries as that would be a bug.

Cheers,
Andy

Re: Backup problem using "cp"

[Dan Purgert]

Richard Owlett wrote:
> On 05/07/2018 06:54 AM, Dan Purgert wrote:
>> Richard Owlett wrote:
>>> [...]
>>> I suspect long term I want "rsync" [ *MUCH* reading to do! ]
>> 
>> Perhaps; although depending on the source / target pathing, you may run
>> into the same length issues.
>> 
>
> 1st - I suspect that --exclude will eliminate multiple pit falls.

Yep, it should.
> 2nd - It appears that cp creates a tangle of sub-directories >100
>levels deep - each sub-directory has same string as its name ;{

If you did something that resolved to stick 'cp' into a recursive loop,
yup that'd definitely happen. Same with rsync.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Backup problem using "cp"

[Richard Owlett]

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


No the _apparent_ line break was an artifact of email quoting process.
I can't rerun the diagnostic at the moment - hardware fully occupied 
with testing my proposed workaround, which works so far but progress 
resembles molasses running uphill on Pluto in winter ;/







I gather that "cp" is then an inappropriate tool.


That's not decided yet.

If your cp target directory had a different device number, then cp option -x
did not what it is supposed to do.

But if your target directory was not the mount point of the USB disk and
not inside the filesystem of the USB disk, then you made a mistake by
giving that directory as target.


Understood.





"tar" is inappropriate for my preferences - I was attempting to use "cp" as
there would be multiple files &/or directories as input *and* output.


You could use multiple tar commands.
(I doubt that you can talk cp into addressing more than one target.)


Communication confusion.
My goal was to copy root and its sub-directory to a directory on another 
physical device.





Have a nice day :)

Thomas

Re: Backup problem using "cp"

[David Griffith]

On May 7, 2018 4:31:16 AM PDT, Richard Owlett  wrote:
>On 05/06/2018 10:11 AM, Thomas Schmitt wrote:
>> Hi,
>> 
>> Richard Owlett wrote:
>>> Thought I was doing that by specifying -x.
>> 
>> Either cp -x has a bug or the target directory is not in a different
>> filesystem than "/" and not a mount point of such a filesystem.
>> 
>> Check the device numbers of "/" and "/media/richard/MISC...".
>> E.g. like this
>> 
>>$ stat / | fgrep Device
>>Device: 803h/2051d  Inode: 2   Links: 25
>>$ stat /bkp | fgrep Device
>>Device: 814h/2068d  Inode: 2   Links: 7
>> 
>> Here "/bkp" has a different device number (2068) than "/" (2051).
>> So it (its inode, to be exacting) is in a different filesystem.
>> 
>> As contrast see a directory in the same filesystem as "/":
>> 
>>$ stat /home | fgrep Device
>>Device: 803h/2051d  Inode: 2228225 Links: 60
>
>I get:
>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
>richard@debian-jan13:~$
>
>I gather that "cp" is then an inappropriate tool.
>
>"tar" is inappropriate for my preferences - I was attempting to use
>"cp" 
>as there would be multiple files &/or directories as input *and*
>output.
>
>I suspect long term I want "rsync" [ *MUCH* reading to do! ]


You will indeed want rsync.  Essentially, "rsync -av [--delete]  
 will serve most of your backup needs.
-- 
David Griffith
d...@661.org

Re: Backup problem using "cp"

[Richard Owlett]

On 05/07/2018 06:54 AM, Dan Purgert wrote:

Richard Owlett wrote:

[...]
I suspect long term I want "rsync" [ *MUCH* reading to do! ]


Perhaps; although depending on the source / target pathing, you may run
into the same length issues.



1st - I suspect that --exclude will eliminate multiple pit falls.
2nd - It appears that cp creates a tangle of sub-directories >100
  levels deep - each sub-directory has same string as its name ;{

I'll likely abandon further immediate investigation of cp. I've other 
projects to complete 

Re: Backup problem using "cp"

[Thomas Schmitt]

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


> I gather that "cp" is then an inappropriate tool.

That's not decided yet.

If your cp target directory had a different device number, then cp option -x
did not what it is supposed to do.

But if your target directory was not the mount point of the USB disk and
not inside the filesystem of the USB disk, then you made a mistake by
giving that directory as target.


> "tar" is inappropriate for my preferences - I was attempting to use "cp" as
> there would be multiple files &/or directories as input *and* output.

You could use multiple tar commands.
(I doubt that you can talk cp into addressing more than one target.)


Have a nice day :)

Thomas

Re: Backup problem using "cp"

[Dan Purgert]

Richard Owlett wrote:
> [...]
> I suspect long term I want "rsync" [ *MUCH* reading to do! ]

Perhaps; although depending on the source / target pathing, you may run
into the same length issues.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Backup problem using "cp"

[Richard Owlett]

On 05/06/2018 10:11 AM, Thomas Schmitt wrote:

Hi,

Richard Owlett wrote:

Thought I was doing that by specifying -x.


Either cp -x has a bug or the target directory is not in a different
filesystem than "/" and not a mount point of such a filesystem.

Check the device numbers of "/" and "/media/richard/MISC...".
E.g. like this

   $ stat / | fgrep Device
   Device: 803h/2051d  Inode: 2   Links: 25
   $ stat /bkp | fgrep Device
   Device: 814h/2068d  Inode: 2   Links: 7

Here "/bkp" has a different device number (2068) than "/" (2051).
So it (its inode, to be exacting) is in a different filesystem.

As contrast see a directory in the same filesystem as "/":

   $ stat /home | fgrep Device
   Device: 803h/2051d  Inode: 2228225 Links: 60


I get:
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
richard@debian-jan13:~$

I gather that "cp" is then an inappropriate tool.

"tar" is inappropriate for my preferences - I was attempting to use "cp" 
as there would be multiple files &/or directories as input *and* output.


I suspect long term I want "rsync" [ *MUCH* reading to do! ]



Any way to accomplish that without explicitly listing all directories except
/media ?


If it is indeed a bug with cp -x, then you could use some archiver like
"tar" which has options to exclude a file.
 > Get inspiration from googling "tar pipe for copying".


Although I wish to avoid "tar", I did get inspiration for a brute force 
method - I'll try it first before commenting.

Re: Backup problem using "cp"

[David Wright]

On Sun 06 May 2018 at 13:55:32 (-0500), Richard Owlett wrote:
> On 05/06/2018 10:38 AM, Pascal Hambourg wrote:
> >Le 06/05/2018 à 16:22, Richard Owlett a écrit :
> >>I'm attempting to backup current partition  to a USB connected 1
> >>TB drive.
> >>
> >>I get:
> >>
> >>>root@debian-jan13:/home/richard# cp -ax / "/media/richard/MISC
> >>>backups/dev_sda14/"
> >>>cp: cannot stat '/media/richard/MISC 
> >>>backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2
> >>>problem-2018-02-13/grub2 problem-2018-02-13/grub2
> >>>problem-2018-02-13/grub2 problem-2018-02-13/grub2
> >>>problem-2018-02-13/grub2 problem-2018-02-13': File name
> >>>too long
> >
> >
> >The same pattern "grub2 problem-2018-02-13" seems to be repeated
> >endlessly in the path. Could there be a loop ?
> >
> >
> 
> Obviously ;/
> I thought I had broken the loop by specifying -x.

The looping has nothing to do with -x, and I see nothing that
indicates -x has failed in its desired effect.

The loop is generating a source filename
/home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13
which is likely within length limits, and resides on the correct
filesytem. However, the destination filename is lengthened by
prefixing it with /media/richard/MISC backups/dev_sda14 which
takes it over the pathname's limit, which is what the error
message states.

Cheers,
David.

Re: Backup problem using "cp"

[Richard Owlett]

On 05/06/2018 10:38 AM, Pascal Hambourg wrote:

Le 06/05/2018 à 16:22, Richard Owlett a écrit :
I'm attempting to backup current partition  to a USB connected 1 TB 
drive.


I get:

root@debian-jan13:/home/richard# cp -ax / "/media/richard/MISC 
backups/dev_sda14/"
cp: cannot stat '/media/richard/MISC 
backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13': File name too long



The same pattern "grub2 problem-2018-02-13" seems to be repeated 
endlessly in the path. Could there be a loop ?





Obviously ;/
I thought I had broken the loop by specifying -x.

Re: Backup problem using "cp"

[Pascal Hambourg]

Le 06/05/2018 à 16:22, Richard Owlett a écrit :

I'm attempting to backup current partition  to a USB connected 1 TB drive.

I get:

root@debian-jan13:/home/richard# cp -ax / "/media/richard/MISC 
backups/dev_sda14/"
cp: cannot stat '/media/richard/MISC 
backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13': File name too long



The same pattern "grub2 problem-2018-02-13" seems to be repeated 
endlessly in the path. Could there be a loop ?

Re: Backup problem using "cp"

[Cindy-Sue Causey]

On 5/6/18, Thomas Schmitt  wrote:
> Hi,
>
> Richard Owlett wrote:
>> Thought I was doing that by specifying -x.
>
> Either cp -x has a bug or the target directory is not in a different
> filesystem than "/" and not a mount point of such a filesystem.
>
> Check the device numbers of "/" and "/media/richard/MISC...".
> E.g. like this
>
>   $ stat / | fgrep Device
>   Device: 803h/2051d  Inode: 2   Links: 25
>   $ stat /bkp | fgrep Device
>   Device: 814h/2068d  Inode: 2   Links: 7
>
> Here "/bkp" has a different device number (2068) than "/" (2051).
> So it (its inode, to be exacting) is in a different filesystem.
>
> As contrast see a directory in the same filesystem as "/":
>
>   $ stat /home | fgrep Device
>   Device: 803h/2051d  Inode: 2228225 Links: 60
>
>
>> Any way to accomplish that without explicitly listing all directories
>> except
>> /media ?
>
> If it is indeed a bug with cp -x, then you could use some archiver like
> "tar" which has options to exclude a file.
>
> Totally untested fantasy:
>
>   $ tar cf - --exclude=/media / | (cd /media/.../dev_sda14 ; tar xf - )
>
> Get inspiration from googling "tar pipe for copying".


I use "--exclude" with rsync so I tried a quick search with that, too.
It's a handy keyword to throw into the search mix.

"tar" and "file" have been coming up for me for specific copy needs
lately, primarily related to plucking via time stamps within large,
single directories. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: Backup problem using "cp"

[Thomas Schmitt]

Hi,

Richard Owlett wrote:
> Thought I was doing that by specifying -x.

Either cp -x has a bug or the target directory is not in a different
filesystem than "/" and not a mount point of such a filesystem.

Check the device numbers of "/" and "/media/richard/MISC...".
E.g. like this

  $ stat / | fgrep Device
  Device: 803h/2051d  Inode: 2   Links: 25
  $ stat /bkp | fgrep Device
  Device: 814h/2068d  Inode: 2   Links: 7

Here "/bkp" has a different device number (2068) than "/" (2051).
So it (its inode, to be exacting) is in a different filesystem.

As contrast see a directory in the same filesystem as "/":

  $ stat /home | fgrep Device
  Device: 803h/2051d  Inode: 2228225 Links: 60


> Any way to accomplish that without explicitly listing all directories except
> /media ?

If it is indeed a bug with cp -x, then you could use some archiver like
"tar" which has options to exclude a file.

Totally untested fantasy:

  $ tar cf - --exclude=/media / | (cd /media/.../dev_sda14 ; tar xf - )

Get inspiration from googling "tar pipe for copying".


Have a nice day :)

Thomas

Re: Backup problem using "cp"

[Richard Owlett]

On 05/06/2018 09:33 AM, Thomas Schmitt wrote:

Hi,

Richard Owlett wrote:

cp -ax / "/media/richard/MISC
backups/dev_sda14/"
cp: cannot stat '/media/richard/MISC
...
File name too long


You tell cp to copy / including its sub tree /media/richard/... which is
the target of the copy process. So as soon as reading reaches that tree
it begins to copy itself into itself endlessly until it bonks against
a filesystem limit.

You need to exclude the target directory from being copied.
E.g. by not giving "/" as copy source but rather all its files and
directories except "/media".



Thought I was doing that by specifying -x.
Any way to accomplish that without explicitly listing all directories 
except /media ?

Re: Backup problem using "cp"

[Dan Purgert]

Richard Owlett wrote:
> I'm attempting to backup current partition  to a USB connected 1 TB drive.
>
> I get:
>
>> root@debian-jan13:/home/richard# cp -ax / "/media/richard/MISC
>> backups/dev_sda14/"
>> cp: cannot stat '/media/richard/MISC
>> backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2
>> problem-2018-02-13/grub2 problem-2018-02-13/grub2
>> problem-2018-02-13/grub2 problem-2018-02-13/grub2
>> problem-2018-02-13/grub2 problem-2018-02-13': File name too long
>
> After multiple re-readings of man page for cp I suspect:
>
> -t, --target-directory=DIRECTORY
>  copy all SOURCE arguments into DIRECTORY
>
> -T, --no-target-directory
>  treat DEST as a normal file
>
> but am actually quite lost.
> HELP please.
> TIA

the filename (including path) is too long for 'cp' to handle.  Might
also hold true for other tools (e.g. rsync).  perhaps just completely
empty the trash? 
-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Backup problem using "cp"

[Thomas Schmitt]

Hi,

Richard Owlett wrote:
> cp -ax / "/media/richard/MISC
> backups/dev_sda14/"
> cp: cannot stat '/media/richard/MISC
> ...
> File name too long

You tell cp to copy / including its sub tree /media/richard/... which is
the target of the copy process. So as soon as reading reaches that tree
it begins to copy itself into itself endlessly until it bonks against
a filesystem limit.

You need to exclude the target directory from being copied.
E.g. by not giving "/" as copy source but rather all its files and
directories except "/media".


Have a nice day :)

Thomas

Backup problem using "cp"

[Richard Owlett]

I'm attempting to backup current partition  to a USB connected 1 TB drive.

I get:


root@debian-jan13:/home/richard# cp -ax / "/media/richard/MISC 
backups/dev_sda14/"
cp: cannot stat '/media/richard/MISC 
backups/dev_sda14/home/richard/.local/share/Trash/expunged/73080846/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13/grub2 
problem-2018-02-13/grub2 problem-2018-02-13/grub2 problem-2018-02-13': File 
name too long


After multiple re-readings of man page for cp I suspect:

-t, --target-directory=DIRECTORY
copy all SOURCE arguments into DIRECTORY

-T, --no-target-directory
treat DEST as a normal file

but am actually quite lost.
HELP please.
TIA