2011/2/26 Branko Čibej <br...@e-reka.si>: > On 26.02.2011 07:32, Ivan Zhakov wrote: >> 2011/2/26 Branko Čibej <br...@e-reka.si>: >>> On 25.02.2011 16:53, Julian Foad wrote: >>>> On Thu, 2011-02-24, Branko Čibej wrote: >>>>> On 24.02.2011 18:03, Julian Foad wrote: >>>>>> On Wed, 2011-02-23, Daniel Shahaf wrote: >>>>>>> julianf...@apache.org wrote on Tue, Feb 22, 2011 at 15:38:35 -0000: >> [...] >> >>>>> It is not the business of the wc_db+pristine-store to track >>>>> every process that happens to have an open handle to the pristine file. >>>>> A deletion of the pristine file should succeed even if there are open >>>>> handles referring to it. >>>> So you're suggesting we should promise that a reader can continue >>>> reading the file (at least once through to the end, not sure about >>>> rewinding) even if something else deletes the file from the store part >>>> way through. I think you're suggesting those semantics are more >>>> reasonable than "you have to hold some sort of lock while you read it", >>>> which is what my design boiled down to. >>> Yes, indeed, they're far more reasonable because the OS already gives >>> them to you. On Unix, when you delete a file, it vanishes from the >>> directory; but open handles remain valid, and the backing store of the >>> data still exists. The file only really goes away when the last handle >>> is closed. >>> >>> On Windows, the situation is pretty much the same (assuming >>> FILE_SHARE_DELETE which we've already determined APR always does -- >>> guess why :), *except* that the file only vanishes from the directory >>> after it's been deleted once the last handle to it is closed, that's why >>> I mentioned the tricky part of re-instating the file. >>> >> [..] >>>> I guess I'll have to figure out how to implement this "trifle more >>>> involved" part on Windows, now. >>> Lucky you, the name of the file is the digest of its contents, so in >>> order to reinstate the file on Windows you only have get the system to >>> twiddle it's "deleted" bit. "Only." I seem to recall that's not even >>> hard to do, but my last battle with Windows filesystem internals was >>> more than 10 years ago. If you can't find relevant docs, you could try >>> asking APR for that functionality. I'm sure Will Rowe will give you a >>> dozen reasons why doing that is not a good idea, and also explain how to >>> do it. :) >>> >> Problem of re-installing file over marked for deletion file can be >> solved using the following trick: >> 1. Rename file to temporary name. >> 2. Delete it > > (If the proper share bits are set.) > Sure.
> Yes, that'd work, but if there's a way to unmark the deletion bit, > that's even better, since then you'd not even have to create another > file (with identical contents). > I'm not aware how to unmark deletion bit on Windows. -- Ivan Zhakov
