Re: [Duplicity-talk] Errors during test phase of installation.....

[Kenneth Loafman]

Ede,

See the message I sent w.r.t. Linux vs Mac permissions and 'rm -r foo/bar'?  That explains the problem on Sierra.  I don't think it has anything to do with tar at all.  I think that El Capitan shell may have different semantics than Sierra and that is potentially causing his problem.  Once I stopped those two tests from running, all went well on Sierra when run as a normal user.  I don't test as root since I think the tests themselves use sudo only if needed.

...Ken

On Mon, Feb 6, 2017 at 6:27 AM, <address@hidden> wrote:

hey Ken,

just checked. OSX uses bsdtar 2.8.3, at least between 10.9 and 10.12.

-p option behaves identical to gnutar.
when run as root it tries to restore owners and permissions.
when run as ordinary user it only restores the permissions as far as possible, ignoring a setup umask.

in conclusion i don't think OSX is at fault here, but i assume it is simply a user error.

..ede/duply.net

On 05.02.2017 18:14, Kenneth Loafman wrote:
> The tests don't run as root, so not sure what you mean by "as root on linux".   The -p option would cause tar to try and make the target owner the same as the original, not the test user, which I'm sure would break things.  Lots of moving parts, and since some of them move relative to ownership of the file, and system platform, it would take a while to untangle.  MacOS is different from Linux is different from BSD.  Root has different defaults than a normal user.
>
> I think a lot of this lies in the BSD'ness of the MacOS vs Linux.
>
> ...Ken
>
>
> On Sun, Feb 5, 2017 at 10:21 AM, <address@hidden <mailto:address@hidden>> wrote:
>
>     Ken,
>
>     i just wonder if
>     - setting a proper umask
>     - switching to the proper user
>     beforehand would mitigate the extraction issue, if it is the initial extraction at all.
>
>     also there is this tar switch, from the manpage https://www.gnu.org/software/tar/manual/tar.html <https://www.gnu.org/software/tar/manual/tar.html>

>     "
>     `--preserve-permissions'
>     `--same-permissions'
>     `-p'
>
>         When tar is extracting an archive, it normally subtracts the users' umask from the permissions specified in the archive and uses that number as the permissions to create the destination file. Specifying this option instructs tar that it should use the permissions directly from the archive. See section Setting Access Permissions.
>     "
>
>     i see your issue with the 'rm -rf' below, but i guess what rm is doing there as root on linux is probably not posix at all and chmod-ing your target beforehand would be expected.
>
>     ..ede
>
>     On 05.02.2017 17:08, Kenneth Loafman wrote:
>     > I'll let Scott answer for El Capitan, but for Sierra, here's the
>     > reproduction.
>     >
>     > On MacOS Sierra:
>     >
>     > address@hidden:~$ mkdir -p foo/bar
>     > address@hidden:~$ rm -r foo
>     > address@hidden:~$ mkdir -p foo/bar
>     > address@hidden:~$ chmod 0000 foo/bar
>     > address@hidden:~$ rm -r foo
>     > rm: foo/bar: Permission denied
>     > rm: foo: Directory not empty
>     > address@hidden:~$ rm -rf foo
>     > rm: foo/bar: Permission denied
>     > rm: foo: Directory not empty
>     >
>     > On Linux:
>     >
>     > address@hidden:~$ mkdir -p foo/bar
>     > address@hidden:~$ rm -r foo
>     > address@hidden:~$ mkdir -p foo/bar
>     > address@hidden:~$ chmod 0000 foo/bar
>     > address@hidden:~$ rm -r foo
>     > rm: descend into write-protected directory 'foo/bar'? y
>     > rm: remove write-protected directory 'foo/bar'? y
>     > address@hidden:~$ rm -rf foo
>     >
>     > It's a fairly major difference if you expect 'rm -rf' to remove everything
>     > you own.  This happens in two tests in
>     > testing/functional/test_selection.py, TestLockedFoldersNoError, lines 982
>     > and 999, at the statements 986 and 1005, thus the check for platform before
>     > those tests.
>     >
>     > ...Ken
>     >
>     >
>     > On Sun, Feb 5, 2017 at 7:28 AM, edgar.soldin--- via Duplicity-talk <

>     > address@hidden <mailto:address@hiddenorg>> wrote:
>     >
>     >> On 04.02.2017 00:23, Scott Hannahs via Duplicity-talk wrote:
>     >>> The other big error was that the un-tar of the test files would set file
>     >> permissions and owners so that the test user could not delete them.   I set
>     >> a note that the testing phase has to run as root.  It shouldn’t but that
>     >> seems to be an issue.  If the no-owner no-group flags were set on the untar
>     >> command for the test directories it might work.  But that may mess up some
>     >> of the tests.
>     >>
>     >> Scott,
>     >>
>     >> can you explain this a little bit more detailed? do you mean that
>     >> untar-ing the duplicity tarball creates files/folders with improper
>     >> permissions?
>     >>
>     >> what do those improper persmissions/owner values look like?
>     >>
>     >> ..ede/duply.net <http://duply.net>
>     >>
>     >> _______________________________________________
>     >> Duplicity-talk mailing list
>     >> address@hidden <mailto:address@hiddenorg>
>     >> https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>     >>
>     >
>
>