At 08:42 PM 9/10/2001 -0600, Justin Simoni wrote:
> > Well, what was your $! when the rename failed? If it was "cross-device
> link",
> > then you attempted something that you really can't do.
>
>I don't think it was anything like that, as with many :) real world
>problems, it's a bit more complicated than that. The file in question on my
>failure was an email subscription list, so an email had to be searched for
>in one file, a new version of this file had to be created that had the
>file's content sans found email and then this list had to be written back
>into where it used to be, so it was something like (reduced to Algorythmic
>fluff for clarity):
>
>
>------------------------------
>
>open OLDFILE, $oldfile;
>open TEMPFILE, $tempfile;
>
>while TEMPFILE
> next if $email eq '$_';
> print TEMPFILE $_;
>end while
>
>close OLDFILE;
>close TEMPFILE;
>
>delete($oldfile);
># ahem
>rename($tempfile, $oldfile);
>
>------------------------------
>a BIG problem with this was that the live file with the subscription list
>was hit several times a second for large lists which also makes the file
>kinda hefty. so, yeah, this was just asking for trouble.
Although I suspect you did it right, I am still curious about the exact
algorithm because it seems ambiguous to me what you did and where your
problem lay.
So by the above, you mean because you'd lock the entire operation? Or are
you saying there is a race condition? I am assuming you have locked and
unlocked the resource (only one updater at a time lock) at the beginning
and end of the routine up above... But in the above scenario it at least
seems as if your reads should always work but you just need to lock on a
2nd resource (exclusive lock so no one can read either) around the delete
and rename operation.
>My solution was to first make my Highlander, 'There shall be only one' temp
>file lock and with that protection, make my temp file with the changes,
>close both the temp and live file, open the live file for overwritting, and
>the temp file for reading, and then just delete the temp file.
At first glance, this sounds dangerous to me. How can you assure that
another process isn't reading the file at the same time if you are opening
the live file for overwriting. Or is a new inode really created at that
point? Even so, is it possible that even if a new file is created, before
you finish writing, for example, the 2nd half of the addresses file,
another process could have tried reading it as the entire distro list and
so fail to do whatever operation it had to do on the 2nd half of the list.
>I'm pretty happy with the performance, as the site that was really having
>problems.. hasn't since we changed this routine and their list is somewhere
>around 70,000 - 100,00, this site is http://redjellyfish.com the software is
>(*cough* shameless plug) http://mojo.skazat.com
>--
>
>justin simoni
>
>personal musings ~ http://skazat.com
>_____________________________________
> force a change
>
>
>
>
>
>On 9/10/01 8:04 PM, "Randal L. Schwartz" <[EMAIL PROTECTED]> wrote:
>
> >>>>>> "Justin" == Justin Simoni <[EMAIL PROTECTED]> writes:
> >
> >>> Yes, and surprisingly enough, it's called "rename". :)
> >
> > Justin> I've had bad luck using rename, I've had to copy the file to
> > Justin> the new name and deep six the old, check out File::Copy, I
> > Justin> think it ironically, has a function called copy(), or even
> > Justin> cp(), my memory eludes me.
> >
> > Well, what was your $! when the rename failed? If it was "cross-device
> link",
> > then you attempted something that you really can't do.
> >
> > But to say in general that "rename" is perhaps broken is a bit too
> > much for me to let stand with no comment.
> >
> > My advice to the original poster: use rename, but be aware that it can
> > only rename within a disk, not across disks.
>
>
>--
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
