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

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>

Replies are listed 'Best First'.
Re^11: locking over the network (rename)
by Corion (Patriarch) on Feb 02, 2011 at 11:23 UTC

    That part does not get called except on Windows 9x. The relevant part since Windows NT onwards is:

    DllExport int
win32_rename(const char *oname, const char *newname)
{
    char szOldName[MAX_PATH+1];
    char szNewName[MAX_PATH+1];
    BOOL bResult;
    dTHX;

    /* XXX despite what the documentation says about MoveFileEx(),
     * it doesn't work under Windows95!
     */
    if (IsWinNT()) {
    DWORD dwFlags = MOVEFILE_COPY_ALLOWED;
        if (stricmp(newname, oname))
            dwFlags |= MOVEFILE_REPLACE_EXISTING;
        strcpy(szOldName, PerlDir_mapA(oname));
        bResult = MoveFileExA(szOldName,PerlDir_mapA(newname), dwFlags
+);
    if (!bResult) {
        DWORD err = GetLastError();
        switch (err) {
        case ERROR_BAD_NET_NAME:
        case ERROR_BAD_NETPATH:
        case ERROR_BAD_PATHNAME:
        case ERROR_FILE_NOT_FOUND:
        case ERROR_FILENAME_EXCED_RANGE:
        case ERROR_INVALID_DRIVE:
        case ERROR_NO_MORE_FILES:
        case ERROR_PATH_NOT_FOUND:
        errno = ENOENT;
        break;
        default:
        errno = EACCES;
        break;
        }
        return -1;
    }
    return 0;

    [download]

    ... which is basically a straightforward call to MoveFileEx() and warrants no judgement on whether it is atomic or not.

[reply]
[d/l]
      ... which is basically a straightforward call to MoveFileEx() and warrants no judgement on whether it is atomic or not.
      And indeed, there is a statement by a Microsoft Support person (Microsoft Online Community Support), which says:

      Based on my knowledge, MoveFileEx should not be an atomic operation.

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

        Yes, I saw that message too, but I would have liked some kind of discussion on the MoveFileEx documentation (or anywhere in the Win32 documentation on file system operations) more asserting. Yet any discussion of the guarantees has eluded me, which was why I asked how you so quickly concluded that it is not atomic.

[reply]

In Section Seekers of Perl Wisdom