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

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;

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

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

      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.