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

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.

  • Comment on Re^9: locking over the network (rename)

Replies are listed 'Best First'.
Re^10: locking over the network (rename)
by rovf (Priest) on Feb 02, 2011 at 10:06 UTC
    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]

      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]

In Section Seekers of Perl Wisdom