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

[edgar . soldin]

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
"
`--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> 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
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>