The Asylum   Search Private Messages Options Blogs Images Chat Cam Portals Calendar FAQ's Join  
Asylum Forums : Powered by vBulletin version 2.2.8 Asylum Forums > WIT - Whore Institute of Technology > perl - windows/ubb file locking - WRAITH READ!
  Last Thread   Next Thread
Author
Thread [new thread]    [post reply]
Dingle
Gay for Mugtoe

Registered: Jul 2000
Location:
Posts: 12791
Post perl - windows/ubb file locking - WRAITH READ!

this is directed specifically at wraith because he's the only other perl programmer around here i know of, but anyone can feel free to respond.

I have always been skeptical of UBB's file locking routine especially considering the number of threads that get fuxx0red around here. Heres the routine:

code:
sub Lock { local ($lockname) = @_; local ($endtime); $endtime = 15; $endtime = time + $endtime; while (-e $lockname && time < $endtime) { open (LOCKFILE, ">$lockname"); } #end lock sr sub Unlock { local ($lockname) = @_; close (LOCKFILE); unlink ($lockname); } } # end Unlock sr #usage &Lock('lock.file'); open (SOMEFILE, ">$path_to_somefile") or die("Unable to open $path_to_somefile"); print SOMEFILE $somedata; close (SOMEFILE); &Unlock('lock.file');


Lock is always passed 'lock.file' (in ubb anyway).
First question is is there any reason to implement Unlock within Lock other than to group them? i believe i read somewhere that declaring a sub inside a sub does nothing to localize the subroutine, meaning its still available globally.

Second, as far as i can see this doesnt do a damned thing.
Lock is called, -e $lockname returns false because lock.file wouldve been erased by the last Unlock call, then returns. Im guessing the intended logic, and i may be way off here, is to continually open lock.file thus (supposedly) preventing other files from being opened while lock.file exists (or the 15 second timeout is reached). if thats the case i think a do-while loop would be more appropriate to create lock.file first, not to mention opening the intended writefile beforehand would help if Lock is supposed to prevent files from being opened, yet even if lock.file DID exist, the sub-routine wouldnt return until it timed out which would mean SOMEFILE wouldnt be open until the lock routine finished which would mean a 15 second hang up that did absolutely nothing. On top of that continually creating a file with a while loop would cause a nice size drop in resources. If that is indeed the intended logic i would think forking a new process to lock the file while it was being written by the parent process would be the only way, or at least an effective way.

As i'm typing this im seriously thinking im missing something important, probably to do with the nested subroutine, after all while im not a huge ubb fan i dont think the authors are THAT dumb! Please enlighten me.

And on a similar front, it has been suggested to me that you dont need to worry about file locking in windows servers as the OS does it for you. Any truth to that? if so the following Lock routine would create a platform independant file locking routine, correct?

code:
sub FLock { my $lkfile = shift; my $operation = shift; if($^O !~ /WIN32/i) { if($operation == 2) { return flock($lkfile, 2); } elsif($operation == 8) { return flock($lkfile, 8); } } else { return 1 } return 0; } #usage open(SOMEFILE, $path_to_somefile); &FLock(SOMEFILE, 2); #read/write to somefile &FLock(SOMEFILE, 8); close SOMEFILE;




[This message has been edited by Dingle (edited 02-16-2001).]

Report this post to a moderator | IP: Logged

Old Post 02-16-2001 11:02 AM
Dingle is offline Click Here to See the Profile for Dingle Click here to Send Dingle a Private Message Find more posts by Dingle Add Dingle to your buddy list [P] Edit/Delete Message Reply w/Quote
Dingle
Gay for Mugtoe

Registered: Jul 2000
Location:
Posts: 12791
Post

or even better:
or even better:

code:
sub FLock { my $lkfile = shift; my $operation = shift; my $result = 0; eval { $result = flock($lkfile, $operation); return $result; }; return 1; } #usage open(SOMEFILE, $path_to_somefile); &FLock(SOMEFILE, 2); #read/write to somefile &FLock(SOMEFILE, 8); close SOMEFILE;





[This message has been edited by Dingle (edited 02-17-2001).]

Report this post to a moderator | IP: Logged

Old Post 02-17-2001 03:19 AM
Dingle is offline Click Here to See the Profile for Dingle Click here to Send Dingle a Private Message Find more posts by Dingle Add Dingle to your buddy list [P] Edit/Delete Message Reply w/Quote
The Wraith
Sergeant of Marines

Registered: Jan 2001
Location: WDM, IA
Posts: 2963
Post

"First question is is there any reason to implement Unlock within Lock other than to group them?"
No. Actually, I generally remove the unlock sub because I've found it only to be of usage when multiple people are editing a post. Generally, this doesn't occur. I was hacking some code and found the unlock was screwing me - removed it, never had a problem with hoarking threads since.

You're right about the logic being skewed. It was a bit of code which was reworked, I forget what version. I don't even worry about locking files for exclusive use.

"...after all while im not a huge ubb fan i dont think the authors are THAT dumb!"
Actually, the code of all 5.x versions and lower are completed screwed up. It's an addon of a fix of an addon of a fix, that has taken place for 5 years. It's become very convoluted and difficult to read. It's why UBB 6 was written from the ground up, adding in all the bugs the author had to fix in 5.x versions. Frankly, the UBB is Ted's first Perl project. He learned as he went. The UBB is by FAR a "well written" program. It has many dificiencies.

"And on a similar front, it has been suggested to me that you dont need to worry about file locking in windows servers as the OS does it for you. Any truth to that?"
True. As I said previously, I don't even worry about it on unix servers. Why would two people (other than user/admin) be editing a post in the first place? It's not something that happens frequently.

------------------------
Regards,
The Wraith

Former Moderator - UBB Code Hacking
Infopop Corporation - Ultimate Bulletin Board
http://www.infopop.com

"Breaker of UBB code, worldwide...Before Infopop started infringing upon individuals 1st Amendment rights. They believe they own what you say on their message boards."

[This message has been edited by The Wraith (edited 02-17-2001).]

Report this post to a moderator | IP: Logged

Old Post 02-17-2001 08:10 AM
The Wraith is offline Click Here to See the Profile for The Wraith Click here to Send The Wraith a Private Message Find more posts by The Wraith Add The Wraith to your buddy list [P] Edit/Delete Message Reply w/Quote
Dingle
Gay for Mugtoe

Registered: Jul 2000
Location:
Posts: 12791
Post

thank you for the info wraith, its nice to know that i dont have to wonder what the hell that routine does anymore.


i dont buy that you dont have to worry about locking files however. as i was learning perl i read somewhere that you need to always lock a file that could potentially be accessed by another process. since that day i have adhered and have never had a bad file created, however UBB seems to spit out bad data files like tacks dick spits loveseed. Now that i have confirmed UBB's file locking routine does absolutely nothing i am even more skeptical that file locking is unneeded.

I am writing some scripts i want to distribute as platform independant. I also wont neglect locking files, so perhaps ill do something as simple as
eval("flock($_[0],$_[1])") or return;
as my flock routine, at least it will be called on systems that support it.

anyways, thanks again.

Report this post to a moderator | IP: Logged

Old Post 02-17-2001 09:28 AM
Dingle is offline Click Here to See the Profile for Dingle Click here to Send Dingle a Private Message Find more posts by Dingle Add Dingle to your buddy list [P] Edit/Delete Message Reply w/Quote
Thimbles worth of opinion
Symetrically challenged

Registered: Aug 2000
Location:
Posts: 12479
Post

Not on windows because unless you specified in the CreateFile call in dwShareMode arg FILE_SHARE_WRITE you will not be able to share access.
Perl (being open standard / open source) probably didn't use any win 32 calls in it's design.
By default read share access is granted, write and delete is denied, and you can get away with renameing anytime. (different IRP to set a files information than to open a handle to read it. HA!)



------------------------
No turkish prison can hold me. But you may for a price.

Report this post to a moderator | IP: Logged

Old Post 02-19-2001 06:52 AM
Thimbles worth of opinion is offline Click Here to See the Profile for Thimbles worth of opinion Click here to Send Thimbles worth of opinion a Private Message Find more posts by Thimbles worth of opinion Add Thimbles worth of opinion to your buddy list [P] Edit/Delete Message Reply w/Quote
All times are GMT. The time now is 08:25 AM. Post New Thread    Post A Reply
  Last Thread   Next Thread
Show Printable Version | Email this Page | Subscribe to this Thread

Forum Jump:
 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is ON
 

< Contact Us - The Asylum >

Copyright © 2014- Imaginet Inc.
[Legal Notice] | [Privacy Policy] | [Site Index]