Re: [PATCH 04/15] Set _O_BINARY as default fmode for both MinGW and MSVC
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Sep 17, 2009, 09:03 UTC
- Message-ID
- <4AB1FB79.5070903@viscovery.net>
- In-Reply-To
- <e2480c70909170139x9580bb4pcc1ad8e1b93aef17@mail.gmail.com>
Alexey Borzenkov schrieb:
Show 10 quoted lines
> On Thu, Sep 17, 2009 at 12:10 PM, Johannes Sixt <j.sixt@viscovery.net> wrote: >> Marius Storm-Olsen schrieb: >>> BTW, I ran all the tests (make /k test) before and after the >>> whole series, with msysgit 'devel' branch + plain git.git 'next', >>> and it turns out that 2 more tests pass after this series :) >> Sorry to disappoint you: these 2 tests only passed by chance. For a >> work-around see e95a73ef in mingw.git (it papers over an undetected >> racily-clean index). > > Maybe we should just implement nsec for mingw? The code is already almost there:
First thing to do is to understand what is going on: There are other architectures that do not have nsec and that do *not* have the problem; why do we have a problem on Windows? If you cannot answer this question, an nsec solution would still just be "it happens to work", and not "it works by design".
I think I had analyzed this particular case, and I understood it, but did not make notes why I found it satisfactory to just paper over the issue, and today I don't remember anymore. :-/
> Since we already reimplement stat/lstat/fstat it should be relatively > simple and we don't care about usage of mingw's stat.
Don't forget utime().
> Do you want me to cook up a patch?
I consider an answer to the question "why do we need nsec?" more important.
BTW: t4130-apply-criss-cross-rename.sh fails quite often as well. This time it is because we fill in st_ino = 0 instead of some useful value. The test moves files around that happen to have identical sizes. After the operation, the dirty working tree could be noticed because st_ino differs from the index. But since we always set it to 0, it is not noticed. (That's my theory.)
If you make a patch, can you think about this issue as well?
-- Hannes