[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locking files for CLASH_DETECTION now supported on MS-Windows

From: Paul Eggert
Subject: Re: Locking files for CLASH_DETECTION now supported on MS-Windows
Date: Mon, 25 Feb 2013 22:05:15 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3

On 02/25/2013 08:02 PM, Eli Zaretskii wrote:> 

> On Windows, as long as a file is open, no
> other application can write to it or remove the file.

Is this true even if the file is network-mounted via NFS or CIFS?
I'd be surprised if it were true for NFS, as that's not the
standard NFS semantics.

> Is that the "atomic" nature you wanted?

Partly, but it's not sufficient.  I assume that one process can
read a file while another is writing to it, which means that
the readlink and symlink replacements may not be atomic.

>> Are readlink, symlink, and unlink atomic on MS-Windows?
> Please define "atomic" for these cases, and I will think about that.

I mean that there's an abstract machine where a symbolic link is
either present or absent, and where readlink ("a", ...),
symlink ("b", "a"), and unlink ("a") either succeed or fail and affect
the abstract machine in an all-or-nothing way.  For example, if
the symbolic link doesn't exist and one process runs
symlink ("very long link contents", "a")
at the same time another process runs readlink ("a", buf, sizeof buf)
where buf is large enough, then the readlink should either fail
(no symlink present yet) or should succeed with
the buffer containing all the link contents; it shouldn't succeed with
partial contents such as "very long link co".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]