Re: copy directory tree, mapping to new owners
On 12/09/21 6:52 pm, john doe wrote:
On 9/12/2021 3:45 AM, Richard Hector wrote:
Thanks, that looks reasonable. It does mean, though, that the files
exist for a while with the wrong ownership. That probably doesn't
matter, but somehow 'feels wrong' to me.
If you are doing this in a script, I would use a temporary directory.
That way, in case of failure the destination directory is not rongly
modified.
EG:
$ rsync <src-dir> <tmp-dir>
Make <tmp-dir> the way you want it to be.
$ rsync <tmp-dir> <dest-dir>
That is true, but firstly it would require more available space, and
secondly, as long as I know about the failure, it doesn't worry me too
much. This is a script I will call manually.
Given that you want to change the ownership, you may want to emulate the
options implied by '-a' but without the ownership option ('-o').
I do that in my existing script (also not -g (group) or -D
(specials/devices (which don't exist there anyway)) - and sometimes -p
(permissions), if I've pre-created the tree with the permissions I want.
The last one is a slightly different use case, but I should make sure I
know which use case I'm trying for ...
My habits would also lead me to do all of the above from above the two
directories in question (in my case, /srv - for /srv/mysite/doc_root and
/srv/mysite_test/doc_root) So:
cd /srv
# actually not necessary? rsync will create it
mkdir -p mysite_test/doc_root
# The trailing / matters. Does it matter on the source as well?
According to the man page it does (1):
"CWrsync -avz foo:src/bar/ /data/tmp
A trailing slash on the source changes this behavior to avoid creating
an additional directory level at the destination. You can think of a
trailing / on a source as meaning lqcopy the contents"
# I generally include it.
In a script, you need to be sure what the cmd does do or not do!!! :)
True. But many options I've learned from my everyday usage, and
sometimes forgotten the rationale - I just know it does what I want :-)
rsync -a mysite/doc_root/ mysite_test/doc_root/ # The trailing /
matters.
find mysite_dest -user mysite -exec chown mysite_test {} +
# I prefer mysite_test-run; it keeps consistency with
# the ${sitename}-run pattern used elsewhere
find mysite_dest -user mysite-run -exec chown mysite_test-run {} +
Have I broken anything there?
Not that I can see but testing will tell!
This is what I would do. And I would do it *interactively*.
If you insist on making a script, then it will be slightly more
complicated, because you'll need to add error checking.
The trouble with doing it interactively, when it needs to be done many
times (and on several sites), is that each time there's opportunity to
make a mistake. And it means the process needs to be documented
separately from the script.
In fact, I'd incorporate the above in a larger script, which does things
like copying the database (and changing the db name in the site config).
Error checking in shell scripts is something I certainly need to learn
At the very least, '<cmd> ['&&'|'||'] handle the error>.
If you use Bash and don't need to be POSIX compliant and /or portable
you can be a bit more creative.
Heh - you've cut my sentence in two, which appears to change the meaning
slightly :-)
" ... is something I need to learn and practice more".
You make it look like I need to learn error checking from scratch :-)
I am using bash. And I am currently using 'set -e' to handle that kind
of error globally. As I say, as long as I can see that it broke, it
doesn't matter too much.
and practice more - I tend to rely somewhat on 'knowing' what I'm
working with, which is probably not a good idea.
>
Yes in a script it is like shooting yourself in the foot.
I do test it.
Cheers,
Richard
Reply to: