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-sprac...@t-online.de> > To: mailing list for gambas users <gambas-user@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@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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user > ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user