in reply to Re^6: locking over the network (rename)
in thread locking over the network

Windows Perl gets built from the same source as Other Perl, so you don't need anything from ActiveState.

Perl calls just the underlying C library, and commonly, at least on POSIX 1 implementations, the C library is a thin wrapper around the rename(3) system call. On Windows, the call to rename is in win32.c.

Replies are listed 'Best First'.
Re^8: locking over the network (rename)
by rovf (Priest) on Feb 01, 2011 at 16:16 UTC
    On Windows, the call to rename is in win32.c.

    Thank you for this link! From what I can see, this shows that rename indeed is *not* atomic on Windows!

    -- 
    Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]

      Where did you find (so quickly) that MoveFileEx is not atomic on Windows? If you're including Windows 95 (and 98 and ME) in your list of things, then yes, there rename is (in a weirdly surprising way) not implemented as atomic operation, but I doubt the prudence of supporting Windows 9x when even Perl does not really care about it anymore (but I can't find the p5p email stating that "no contortions for supporting Win9x will be made", so that may be wishful thinking here).

      Update: Building on Win9x is unsupported

      Update: Windows 95 Chainsaw Massacre - it seems that some code in 5.12 survived this, but that's to be expected of a maintenance release. At least 5.14 won't support Windows 9x anymore.

[reply]
        Where did you find (so quickly) that MoveFileEx is not atomic on Windows?
        On the page where you gave me the link. To be more precises: I could not see that atomicity would be guaranteed. To quote the part of that page which I believe to be relevant: 
        1499:   /* CRT is buggy on sharenames, so make sure it really isn't.
3259:win32_rename(const char *oname, const char *newname)
3314:   /* if newname exists, rename it to a temporary name so that we
3348:       retval = rename(szNewName, szTmpName);
3355:   /* rename oname to newname */
3356:   retval = rename(szOldName, szNewName);
3360:       /* ...and rename succeeded, delete temporary file/director
+y */
3365:           (void)rename(szTmpName, szNewName);

        [download]
        So, the renaming is win32_rename is just forwarded to the rename() function, and I couldn't find anything which would guarantee us that this would be atomic.

        I am willing to believe that this 'rename' will work atomically, if experienced Windows developer tell me so. It's just that I couldn't see this from the documentation.

        -- 
        Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom