[Gambas-user] Locking files - best method

[Rolf-Werner Eilert]

That's right. I tried your idea, and it works fine as long as every 
other program keeps looking for the dirs.

My problem is similar: Part of the software runs on Windows, originally 
programmed with VB5. To make it compatible to the Linux side client, I 
introduced a lock-file scheme. It still uses that successfully. 
Unfortunately, I lost the VB source over the years :-( so it has to keep 
on running like that, and so has the Linux client. Luckily, though, we 
are only 2 persons in our offices who use this thing on a daily basis, 
so it's no harm. There are some other Linux programs meanwhile using the 
data, but do not write to it, so no real danger.

But for my next-generation tool for the teachers there was trouble with 
my lock-file system, so I changed writing/reading to your lock-directory 
system. Easy thing, and up to now (a week or so...) it seems to be 
running well. I cannot use Benoits LOCK Stream here because this program 
is still Gambas1.

I had your idea of waiting, but writing "nevertheless" and just give a 
warning as you do is even better. Maybe I'll change that part, but I'd 
prefer keeping the original and writing into temporary files until Admin 
cares about it... :-) As this application has a messaging system, I 
could even send me a message in this case!

Regards

Rolf


nando schrieb:
> I think you're looking for the filesystem to prevent you from file operations
> while 'locked'.  I used 'locking' with VB5 and relied on Window's internal locking
> mechanism. After years of agony, I found the external subdirectory method
> the best.  I don't have shared files on just one computer, there are many computers.
> I found that VB5 sometimes got stupid and never unlocked - especially when
> long time between reboots.  But now, with the subdir method, I can fully control it.
> I do this with Gambas using Samba while I port away from VB5.
> 
> The main problem is this:
> Program 1 locks a file (or a portion of a file) and that program freezes up, 
> locks up, computer is shutdown, etc WHILE the lock is in force.
> Then other programs try the same and....
> The whole system is screwed!
> Now that I use subdirs, I know that a lock 'should be' free (ie unlocked)
> within 10 seconds because I know that there is no way my code should last
> that long....and something is wrong.  In such a case, I can actually
> proceed (fake re-locking it) with the second program, give a warning message
> that it couldn't lock because it is taking too long but is proceeding
> and will subsequently unlock (rmdir) too.
> In very few cases, I have had to go in and RMDIR manually because things
> got jammed up, but discovered those situations to be wierd-condition bugs
> which are now fixed.
> Personally, I like the full control it provides and works over multiple
> programs and multiple computers.
> 
> 
> ---------- Original Message -----------
> From: Rolf-Werner Eilert <eilert-sprachen at ...221...>
> To: mailing list for gambas users <gambas-user at lists.sourceforge.net>
> Sent: Mon, 16 Feb 2009 08:33:12 +0100
> Subject: Re: [Gambas-user] Locking files - best method
> 
>> 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
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Gambas-user mailing list
>> Gambas-user at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gambas-user
> ------- End of Original Message -------
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>