Re: Re: Re: Re: Lock Effectivity

[grantm]

On Win32 trying to open a file for write that is locked is an 'Access is denied' error.

Perhaps that's the case if another process has opened the file and used mandatory locking. However, this snippet certainly behaves as expected on Win32 (ie: a second instance successfully opens the locked file and waits for the lock to be released):

use Fcntl qw(:flock);

open(FILE, ">sem.lck") or die $!;
print "Opened file\n";

flock(FILE, LOCK_EX) or die $!;
print "Got lock\n";

sleep(10);

close(FILE);

I do exactly this on Win32 all the time.

You're right, there is a potential race condition if you want to lock the file you're editing and you need to create it if it doesn't exist. The way around that is to use sysopen like this:

sysopen(FILE, $path, O_RDWR|O_CREAT|O_EXCL) or die $!;

The O_CREAT flag specifies that the file should be created if it does not exist and the O_EXCL specifies that the create should fail if the file does already exist. But this quickly gets complicated because you need to use one form if the file doesn't exist and another if it does. That's why it is so much simpler to use a separate file for locking than the file you're editing.

[demerphq]

Perhaps that's the case if another process has opened the file and used mandatory locking.

I have to admit that until about 10 minutes ago I thought I had flock under Win32 completely under control. Obviously I dont. Thank you very much for taking the time to correct me even though I obviously wasn't listening properly the first time.

But I also have to admit that this doenst make sense to me. I was under the impression that locks are mandatory on Win32. And evidence that they are abounds. For instance the script you wrote (I called it flock_test.pl) if you run it like

D:\perl\scratch>(start flock_test.pl) && (perl -e "sleep 2") && (echo 
+"foo" > sem.lck)
The process cannot access the file because it is being used by another
+ process.

So we know that some other processes cant access the file once its locked. But if we do

D:\perl\scratch>(start flock_test.pl) && (perl -e "sleep 2") && (flock
+_test.pl)
Opened file
Printed
Got lock

Which while proving your point, only leave me even more confused. The way i understood Win32's locking implementation, if the file is locked, then nothing else can mess with the file. So what gives? Why does the shell get blocked from truncating the file, but perl doesn't!?


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}

[grantm]

I have to admit that until about 10 minutes ago I thought I had flock under Win32 completely under control.

Ditto :-)

Here's a bit of wild speculation. Perhaps the shell tries to get a lock on any file it opens for writing. If the (non-blocking) lock request is refused then it gives the error you see. If it were Linux, strace would confirm or deny that theory in a minute but of course it's not :-(