Re: (cp) How to copy a file to an external HDD?

ld be most appreciated. I suggest that you buy and read "Learning the Unix Operating System": https://www.oreilly.com/library/view/learning-the-unix/0596002610/ It will teach you how to use a terminal, shell commands, and userland programs (such as cp(1)). David

Re: (cp) How to copy a file to an external HDD?

On Sat, 13 Aug 2022 at 01:50, Amn wrote: > In learning how to create shell script files, I have come across the > need to move/copy files from one HDD to an external HDD. In MS I would > just "copy c:*.doc b:alldocs", but in Linux is a bit different. How do I > do that in Linux? > Any help

Re: (cp) How to copy a file to an external HDD?

t, and possibly automated, it is a matter of using cp to make the copy. Or something else, depending on what you have in mind. This sounds suspiciously like a backup script, to be run from time to time. Do, by all means, get it working with cp. But then look at using rsync to eliminate redundant copie

Re: (cp) How to copy a file to an external HDD?

On Fri, Aug 12, 2022 at 11:49:39AM -0400, Amn wrote: > In learning how to create shell script files, I have come across the need to > move/copy files from one HDD to an external HDD. In MS I would just "copy > c:*.doc b:alldocs", but in Linux is a bit different. How do I do that in > Linux? Not

(cp) How to copy a file to an external HDD?

In learning how to create shell script files, I have come across the need to move/copy files from one HDD to an external HDD. In MS I would just "copy c:*.doc b:alldocs", but in Linux is a bit different. How do I do that in Linux? Any help would be most appreciated.

Re: unexpected behavior of cp and mv

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959211 On 4/30/20 3:52 PM, The Wanderer wrote: On 2020-04-30 at 15:27, Alberto Sentieri wrote: I run tcpdump while running my simple program on both stretch and buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while on buster it

Re: unexpected behavior of cp and mv

Thanks for the information. I will enter a bug report asking for a fix for the last stretch available samba server. Or maybe for cifs-utils on buster side. On 4/30/20 3:52 PM, The Wanderer wrote: On 2020-04-30 at 15:27, Alberto Sentieri wrote: I run tcpdump while running my simple program

Re: unexpected behavior of cp and mv

On 2020-04-30 at 15:27, Alberto Sentieri wrote: > I run tcpdump while running my simple program on both stretch and > buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while > on buster it uses SMB2 (version 2 or 3). > > So, the problem can be solved by adding vers=1.0 to

Re: unexpected behavior of cp and mv

I run tcpdump while running my simple program on both stretch and buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while on buster it uses SMB2 (version 2 or 3). So, the problem can be solved by adding vers=1.0 to mount.cifs options. Any version from 2.0 and above will incur in

Re: unexpected behavior of cp and mv

, happens in cp. It may not be utimensat. Between the kernel and the smb, there is a cifs package (the driver) which could be doing it wrong. Both the kernel and cifs package are different between the two workstations. Thanks, Alberto On 4/30/20 1:32 PM, Thomas Schmitt wrote: Hi, Alberto

Re: unexpected behavior of cp and mv

t; work when the destination file is on a SMB file system. > > I wrote a simple C program, which I compiled with . > > On my debian buster workstation, I run the program using a script, which is: > > #!/bin/bash > NAME='/mnt/u1/rw/receipt/test2.txt' > rm -f "${NAME}" >

Re: unexpected behavior of cp and mv

Hi, Alberto Sentieri wrote: > ls -ls "${NAME}" > Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result: > 1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt > [...] > I run the same binary and script on my debian stretch workstation, and got > 4 -rwxr-xr-x 1 u1 u1

Re: unexpected behavior of cp and mv

, which I compiled with . On my debian buster workstation, I run the program using a script, which is: #!/bin/bash NAME='/mnt/u1/rw/receipt/test2.txt' rm -f "${NAME}" ls -ls "${NAME}" /mnt/1g/home/u1/data/cp-pi/x2 "${NAME}" ls -ls "${NAME}" sleep 1 ls -ls &qu

Re: unexpected behavior of cp and mv

tests: #!/bin/bash rm -f /mnt/u1/rw/receipt/u1.crontab /bin/stat /mnt/u1/rw/receipt/u1.crontab /bin/cp -pi /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab /bin/stat /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1

Re: unexpected behavior of cp and mv

Hi, Alberto Sentieri wrote: > I tried setfattr as you suggested with "user" and without "user". Both > failed with "Operation not supported" and none of them changed the > timestamp. This only leaves the idea to mimick the strace of cp -p in an own C

Re: unexpected behavior of cp and mv

our will, try -n "test_name", without prefix "user.".) Alberto Sentieri wrote: So, the cp behavior on debian stretch and buster seems to be the same. But the implementation of the system calls is not. touch does the trick of dup2 and close, before calling utimensat. Hm. To verify

Re: unexpected behavior of cp and mv

/home/u1/data/u1.crontab $ cp -pi /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/ $ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab    4 -rw-r--r-- 1 u1 u1 54 Feb  5  2017 /mnt/1g/home/u1/data/u1.crontab 1024 -rwxr-xr-x 1 u1 u1 54 Apr 30 00:00 /mnt/u1/rw/receipt/u1.crontab

Re: unexpected behavior of cp and mv

Exactly as shown on my screen,  it shows that rsync, when used with -av, works as expected, but cp -pi does not. $ rm /mnt/u1/rw/receipt/u1.crontab $ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab ls: cannot access '/mnt/u1/rw/receipt/u1.crontab': No such file or directory

Re: unexpected behavior of cp and mv

On Wed 29 Apr 2020 at 15:07:52 (-0400), Alberto Sentieri wrote: > When I tried strace with /bin/cp -pi I can see on both commands > something like this: > > utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /* > 2020-04-29T11:31:03.908624390-0400 */, {tv_sec=148635

Re: unexpected behavior of cp and mv

Alberto Sentieri wrote: > On 4/29/20 4:13 PM, Thomas Schmitt wrote: >> Hi, >> >> Alberto Sentieri wrote: >>> It is clear >>> there that -p has no effect on that particular case of smb destinations. A >>> similar problem is happening with mv. >> Maybe its not the file copying operation but the

Re: unexpected behavior of cp and mv

n not supported" error as in strace. If it succeeds against our will, try -n "test_name", without prefix "user.".) Alberto Sentieri wrote: > So, the cp behavior on debian stretch and buster seems to be the same. But the implementation of the system calls is not. >

Re: unexpected behavior of cp and mv

Just to document what I've seen so far: These are some straces which may help finding the problem: 1) cp -p  from ext4 to smb, debian buster, which failed: utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /* 2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336, tv_nsec

Re: unexpected behavior of cp and mv

The content file is copied correctly. And touch works as expected on smb files. The command below produced the expected results: touch -t 201901011300  /mnt/u1/rw/receipt/u1.crontab On 4/29/20 4:13 PM, Thomas Schmitt wrote: Hi, Alberto Sentieri wrote: It is clear there that -p has no

Re: unexpected behavior of cp and mv

Hi, Alberto Sentieri wrote: > It is clear > there that -p has no effect on that particular case of smb destinations. A > similar problem is happening with mv. Maybe its not the file copying operation but the subsequent adjustment of the timestamps. Did you already try whether you can change

Re: unexpected behavior of cp and mv

is different from buster, when copying a file with -pi from ext4 to smb. On 4/29/20 3:16 PM, Charles Curley wrote: On Wed, 29 Apr 2020 12:22:41 -0400 Alberto Sentieri <2...@tripolho.com> wrote: cp and mv are not preserving the file timestamps when copying from a ext4 file system to

Re: unexpected behavior of cp and mv

On Wed, 29 Apr 2020 12:22:41 -0400 Alberto Sentieri <2...@tripolho.com> wrote: > cp and mv are not preserving the file timestamps when copying from a > ext4 file system to a smb file system. What I see is: * mv does preserve the time of the file, regardless of copying to an

Re: Re: unexpected behavior of cp and mv

When I tried strace with /bin/cp -pi I can see on both commands something like this: utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /* 2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336, tv_nsec=481422339} /* 2017-02-05T22:05:36.481422339-0500 */], 0) = 0 The utimensat

Re: Re: unexpected behavior of cp and mv

Exactly the same behavior for /bin/cp and /bin/mv. I do not have any other cp or mv in my path. $ sha1sum /bin/cp /bin/mv 220687a082fb9d0dbb48e9a2b1093cbb4e9de55a /bin/cp 46e71d67df7eb1c41f8f8c9039f401e242cce94a /bin/mv On Wed, Apr 29, 2020 at 12:22:41PM -0400, Alberto Sentieri wrote: cp

Re: unexpected behavior of cp and mv

On Wed, Apr 29, 2020 at 12:22:41PM -0400, Alberto Sentieri wrote: > cp and mv are not preserving the file timestamps when copying from a ext4 > file system to a smb file system. > > I am running cp and mv on: > $ lsb_release -a > No LSB modules are available. > Dist

unexpected behavior of cp and mv

cp and mv are not preserving the file timestamps when copying from a ext4 file system to a smb file system. I am running cp and mv on: $ lsb_release -a No LSB modules are available. Distributor ID:    Debian Description:    Debian GNU/Linux 10 (buster) Release:    10 Codename:    buster SMB

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

ctory 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

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

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

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_

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

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

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

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

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

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

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

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

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

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

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

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

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

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 '/med

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

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

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

-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

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

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

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

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

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

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

Re: Backup problem using "cp"

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

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

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

Re: Backup problem using "cp"

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

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

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

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

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=" > "; >

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

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

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

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

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

ories? 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 sh

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

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

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

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*

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

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

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

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:

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

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

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

t / | 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 direct

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

/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 / "/med

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

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

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

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 in

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

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 tr

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

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

Re: Backup problem using "cp"

On Mon 07 May 2018 at 09:11:08 (-0500), Richard Owlett wrote: > On 05/07/2018 08:49 AM, Thomas Schmitt wrote: > >Hi, > > > >Andy Smith wrote: > >>It would still be good to establish why "cp -x" was seemingly able > >>to cross filesystem boundaries a

Re: Backup problem using "cp"

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

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 director

Re: Backup problem using "cp"

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 te

Re: Backup problem using "cp"

On Mon, 7 May 2018, Kushal Kumaran wrote: Date: Mon, 7 May 2018 13:15:48 From: Kushal Kumaran <kus...@locationd.net> 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.deb

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

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 <rowl...@cloud85.net> wrote: On 05/06/2018 10:11 AM, Thomas Schmitt wrote: Hi, Richard Owlett wrote: Thought I was doing that by specifying -x. Either

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

s 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

Re: Backup problem using "cp"

On 08/05/18 00:55, David Griffith wrote: > On May 7, 2018 4:31:16 AM PDT, Richard Owlett <rowl...@cloud85.net> wrote: >> On 05/06/2018 10:11 AM, Thomas Schmitt wrote: >>> Hi, >>> >>> Richard Owlett wrote: >>>> Thought I was doing that by speci

Re: Backup problem using "cp"

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 outr

Re: Backup problem using "cp"

On 05/07/2018 07:55 AM, David Griffith wrote: On May 7, 2018 4:31:16 AM PDT, Richard Owlett <rowl...@cloud85.net> 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 dir

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

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 b

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

On May 7, 2018 4:31:16 AM PDT, Richard Owlett <rowl...@cloud85.net> 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 targ

Re: Backup problem using "cp"

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

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

Re: Backup problem using "cp"

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:

Re: Backup problem using "cp"

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 "

Re: Backup problem using "cp"

;>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/gru

Re: Backup problem using "cp"

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 '/med

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

On 5/6/18, Thomas Schmitt <scdbac...@gmx.net> 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

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

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 p

Re: Backup problem using "cp"

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

Re: Backup problem using "cp"

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

Backup problem using "cp"

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 probl

Re: viewing pictures with gmediarender / gupnp-av-cp

On Sat, 24 Dec 2016, Pierre Frenkiel wrote: I try to display pictures from dlna servers, using gmediarender and gupnp-av-cp. That almost works, but just a part of the pictures are displayed (the upper left part, i.e. 1/4 of the pictures) I didn't find any configuration for these programs. Does

viewing pictures with gmediarender / gupnp-av-cp

hi, I try to display pictures from dlna servers, using gmediarender and gupnp-av-cp. That almost works, but just a part of the pictures are displayed (the upper left part, i.e. 1/4 of the pictures) I didn't find any configuration for these programs. Does anyone have an idea? best regards

Re: Problem selecting options for cp command

On 09/05/2016 05:21 PM, Richard Owlett wrote: > "archive" had brought up mental image of dusty back rooms where things > were being preserved for posterity. Not making a copy to actually be used. > > Someone had suggested rsync but that has too many options for me to > b

  1   2   3   4   5   6   7   8   >