Path: csiph.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!bofh.it!news.nic.it!robomod From: Richard Hector Newsgroups: linux.debian.user Subject: Re: copy directory tree, mapping to new owners Date: Mon, 13 Sep 2021 01:50:02 +0200 Message-ID: References:

X-Mailbox-Line: From debian-user-request@lists.debian.org Sun Sep 12 23:45:21 2021 Old-Return-Path: X-Amavis-Spam-Status: No, score=-7.675 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, BODY_8BITS=1.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LDO_WHITELIST=-5, NICE_REPLY_A=-1.975] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -4.6 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Mailing-List: archive/latest/780645 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/5e1524c9-1c6e-24c1-2c0b-1da7d95935e6@walnut.gen.nz Approved: robomod@news.nic.it Lines: 115 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Mon, 13 Sep 2021 11:45:02 +1200 X-Original-Message-ID: <5e1524c9-1c6e-24c1-2c0b-1da7d95935e6@walnut.gen.nz> X-Original-References:

<605b16e4-86ee-e0b5-4c4c-3495e081b60d@mail.com> Xref: csiph.com linux.debian.user:239934 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

> > Make the way you want it to be. > > $ rsync

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, ' ['&&'|'||'] 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