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

[Paul Eggert <eggert@cs.ucla.edu>]

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".