On 2015-01-22 23.07, Junio C Hamano wrote:
> Torsten Bögershausen <[email protected]> writes:
>
>> If I run that sequence manually:
>> chmod 755 .
>> touch x
>> chmod a-w .
>> rm x
>> touch y
>>
>> x is gone, (but shoudn't according to POSIX)
>> y is not created, "access denied"
>
> Good (or is that Sad?).
It feels that this is by design:
In old days under MS/DOS the only way to hinder people
from deleting a file was to make it "read only" with help
of the ATTRIB command.
https://en.wikipedia.org/wiki/ATTRIB
Later NTFS introduced the (ACL like) secutity information,
and (unless I am completely wrong) the "delete file" is part
of the "modify" permission, not write.
>
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -1039,7 +1039,17 @@ test_lazy_prereq NOT_ROOT '
>> # When the tests are run as root, permission tests will report that
>> # things are writable when they shouldn't be.
>> test_lazy_prereq SANITY '
>> - test_have_prereq POSIXPERM,NOT_ROOT
>> + mkdir ds &&
>> + touch ds/x &&
>> + chmod -w ds &&
>> + if rm ds/x
>> + then
>> + chmod +w ds
>> + false
>> + else
>> + chmod +w ds
>> + true
>> + fi
>> '
>
> It looks like a better approach overall.
>
> Because we cannot know where $(pwd) is when lazy prereq is evaluated
> (it typically is at the root of the trash hierarchy, but not always)
> and we would not want to add, leave or remove random files in the
> working tree that are not expected by the tests proper (e.g. a test
> that counts untracked paths are not expecting ds/ to be there), your
> actual "fix" may need to be a bit more careful, though.
>
> Thanks.
>
So true, what is a better place or way to run the test ?
Can we use /tmp (Which may be a different file system)?
Or can we use $HOME/$$ds (Which is an artificial HOME)
We already "pollute" the $PWD here
test_lazy_prereq CASE_INSENSITIVE_FS '
echo good >CamelCase &&
echo bad >camelcase &&
test "$(cat CamelCase)" != good
'
and here:
test_lazy_prereq UTF8_NFD_TO_NFC '
....
Would
mkdir $HOME/ds
be a better approach then ?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
