Hi, [excluding make-w32 list as per explicit request] On Mon, 15 Oct 2007, Brian Dessent wrote: > Alex Riesen wrote: > > > He misunderstood. It is not what you meant. You cannot remove the open > > file. What he talks about is removing the file after it is _closed_. > > Junk. > > I did not misunderstand. The semantics are equivalent to the POSIX > case: you end up with a handle to an open file that is exclusive to that > process (it cannot be opened by any other process, even root) and that > is automatically reclaimed by the filesystem when all open handles are > closed, without any explicit action by the user. It's not "unlinking an > open file", no, but it's the same result. No, it is not equivalent. For example, you can still see the file. For example, you cannot reuse the filename for another file. And -- the killer -- you cannot remove the directory which contains the file. But really, we have workarounds in place to make this a non-issue. My bigger concerns are the performance and stability. For example, I had a very annoying problem on one of the machines I am testing msysGit on. The problem was _only_ fixable by deactivating component of Logitech's WebCam driver! Now, if a user-installable 3rd party program can make my regular git crash, I am scared what more it can do. Ciao, Dscho - 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
