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.

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>

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.

That's why I hoped that the Perl documentation would give some "guarantees" about this issue

Really? After saying this:

I don't know how to verify this because I am using the ActiveState ... and don't know where to get the sources ... I would need to know which version of which C compiler was used to create this distribution, and whether the rename in the compiler's library works in the expected way.

So you hoped Perl docs would say "We can guarantee that no provider of Perl will ever change the source code nor use a C library such that ..." ?

So you hoped Perl docs would say "We can guarantee that no provider of Perl will ever change the source code nor use a C library such that ..." ?

For any feature of an implementation of a programming language - and Perl's rename is not an exception -, the implementation can either guarantee a certain behaviour, or let the behaviour be undefined. I don't know whether it is, in this case, possible to guarantee atomicity for rename. Reading through the postings in this thread, some contributors seem to be sure that I can rely on atomicity for the platforms I'm running Perl one, Corion doubted that this could be guaranteed with NFS (a point where rowdog disagrees), and so on. I don't have the knowledge to jugde about the conditions, under which I can rely on rename's atomicity, but, yes, I had hoped that IF such guarantees can be done, they would be documented at least in perlport. Of course, IF such guarantees can NOT be done, I don't expect the Perl docs to point this out (this would be too much to ask), but then it would be safer not to rely on this feature and stick with my cooperative solution regarded cooperative locking.

Of course if a provider of a Perl distribution compiles Perl with a buggy compiler (say), then whatever guarantees we find in the Perl docs, they are not necessarily true anymore - the old "garbage-in, garbage-out" principle.

-- 
Ronald Fischer <ynnor@mm.st>

then it would be safer not to rely on this feature and stick with my cooperative solution regarded cooperative locking

Did you try it? It is pretty easy to implement a test where you have process "A" lock until you press Enter and then see if process "B" blocks until then and then vice versa.

I don't think anybody addressed "your current solution". A couple of quick google searches indicate to me that the different things used to implement Perl's flock (usually flock or fcntl's F_GETLK on Unix and LockFileEx on Windows) won't reach across operating systems.

- tye