On 2015-01-22 23.07, Junio C Hamano wrote: > Torsten Bögershausen <tboegi@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html