2011/2/26 Branko Čibej <brane_at_e-reka.si>:
> On 26.02.2011 07:32, Ivan Zhakov wrote:
>> 2011/2/26 Branko Čibej <brane_at_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:
>>>>>>> julianfoad_at_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
Received on 2011-02-26 10:51:49 CET