public inbox for
 help / color / mirror / Atom feed
From: "Lemke, Michael  SF/HZA-ZE2E" <>
To: "" <>
Subject: RE: When only rsync will do .. or maybe not
Date: Fri, 14 Oct 2022 15:35:13 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On October 14, 2022 3:36 PM Cyrille Lefevre wrote:
>Le 12/10/2022 à 12:55, Fergus Daly a écrit :
>> Requirement: to move some selected files and folders under /folder1/ to /folder2/, preserving full pathnames.
>> Using cp with the switch --parents (taking care over syntax and importantly location $PWD) it is possible to _copy_ the
>> Required content across from /folder1/ to /folder2/ but there does not seem to be a matching switch for mv that would
>> achieve the same purpose.
>> One solution would be (i) to copy the required content to /folder2/ and then (ii) delete the identical content under /folder1/;
>> but this is expensive (one might not even have the disk space to do it) and it seems seriously unsatisfactory and not without risk
>> to have to copy folders and files (possibly huge) when all one wants to do is to change the {pathname} to them.
>> Question 1
>> Would the command (or something like it, again with care over syntax and $PWD)
>> $ rsync -axuv --progress {pathto}/folder1/{content} {pathto}/folder2/
>> do the trick? Or is the very existence of the switch
>> $ rsync -axuv --remove-source-files --progress {pathto}/folder1/{content} {pathto}/folder2/
>> indicative that here too the "move" is achieved through a two-stage "copy-then-delete" operation?
>> Question 2
>> If rsync can provide a genuine "move" capability then is installing the rsync package adequate to the purpose;
>> or would librsync-devel and/or librsync2 packages need to be installed also?
>> Question 3
>> If not rsync, is there any operation for which "move" can be achieved without involving "copy-then-delete"?
>> Thank you for any assistance.
>how about find /source | cpio -pdml /target
>alternative, cp -alu --parent /source /target
>then purge /source

Another idea: instead of copies create hardlinks in /folder2 (ln without -s) and then use 'find /folder1 -links 2 ...' to remove the originals. Exact syntax left as an exercise to the reader. Method is a little fragile if hardlinks exist in /folder1. Use with caution. Additional space required is just the directory entries.


  reply	other threads:[~2022-10-14 15:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 10:55 Fergus Daly
2022-10-14 13:36 ` Cyrille Lefevre
2022-10-14 15:35   ` Lemke, Michael  SF/HZA-ZE2E [this message]
2022-10-22 14:39 ` Andrey Repin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).