[Gambas-user] Locking files - best method

Benoît Minisini gambas at ...1...
Tue Dec 28 15:34:13 CET 2010


> Benoît Minisini schrieb:
> >> Sharing a file exclusively locked very briefly and getting everything
> >> to work correctly amongst multiple programs can be brain-twisting.
> >> With increasing use of mulit-cores, the possibility for sharing files
> >> using any lock technique is more important than ever before
> >> because all associated programs can execute simultaneously.
> > 
> > You can use the LOCK/UNLOCK commands and a specific void file on the disk
> > to create system exclusive sections in your code.
> > 
> > Let's suppose you want to modify a file named "/tmp/foo".
> > 
> > ...
> > DIM hLock AS Stream
> > DIM hFile AS Stream
> > 
> > ' Try to acquire the lock
> > TRY hLock = LOCK "/tmp/foo.lock"
> > IF ERROR THEN
> > 
> >   PRINT "'foo' is being modified. Try again later."
> >   RETURN
> > 
> > ENDIF
> > 
> > ' Lock was acquired, you can modify the file now!
> > hFile = OPEN "/tmp/foo" FOR OUTPUT
> > ...
> > CLOSE #hFile
> > 
> > ' Do not forget to release the lock
> > UNLOCK hLock
> > ...
> 
> IMHO "the one" drawback remains: foo.lock isn't foo. You cannot lock the
> file itself, relying on the operating system / the file system to really
> make sure nobody else is able to corrupt your file during your access.
> 
> If there's some other app that doesn't care about .lock files, your
> /tmp/foo will be lost. Of course, the same applies to my own methods
> like lock directories or self-made lock files.
> 
> 
> The only way to solve this would be a mechanism in the file system
> itself, giving the opportunity to code something like
> 
> hFile = OPEN "/tmp/foo" FOR OUTPUT LOCK
> 
> which would unlock the file automagically when you CLOSE it (or the
> instance of your application ends).
> 
> Regards
> 
> Rolf
> 

I add that to my TODO file.

Regards,

-- 
Benoît Minisini




More information about the User mailing list