Question

[Brian K. White]

----- Original Message ----- 
From: "Bill Vermillion" <fp at wjv.com>
To: "filePro List" <filepro-list at lists.celestial.com>
Sent: Saturday, January 15, 2005 12:55 AM
Subject: Re: Question


> On Fri, Jan 14 17:35 , Brian K. White moved his mouse, rebooted for the
> change to take effect, and then said:"
>
>>
>> ----- Original Message ----- 
>> From: "Bill Vermillion" <fp at wjv.com>
>> To: "filePro List" <filepro-list at lists.celestial.com>
>> Sent: Friday, January 14, 2005 4:22 PM
>> Subject: Re: Question
>>
>>
>> >When asked his whereabouts on Fri, Jan 14 15:43 , Walter Vaughan took 
>> >the
>> >fifth, drank it, and then slurred:
>> >
>> >>Jay R. Ashworth wrote:
>> >>>On Fri, Jan 14, 2005 at 03:19:19PM -0500, Fairlight wrote:
>> >>>>At Fri, Jan 14, 2005 at 02:43:52PM -0500 or thereabouts,
>> >>>>suspect Courtney was observed uttering:
>> >>>>>One of the reps here wants a report every other Friday...I was
>> >>>>>thinking
>> >>>>>of
>> >>>>if runfile exists (run report; remove runfile)
>> >>>>if runfile does not exist (create runfile)
>> >>>>....And I'd simply set this logic to run -every- Friday.  No worrying
>> >>>>about
>> >>>>dates, etc.  It just flip-flops.
>> >
>> >>Screw it. Set cron to run the report every Friday. Some stupid
>> >>holiday/lunar event is going to make him want you to change from even
>> >>week of the year Fridays to odd ones and back.
>> >
>> >Or set the day in cron as   5/2   which means every other Friday.
>> >
>> >I find the ability to use the /N in modern crons a great help
>> >intead of all the n,n,n,n,n,n,n,n thingys.
>
>> >I don't know if the @weekly/2  would work, because the @<field>
>> >are special
>
>> sco's cron doesn't support the / syntax
>
> It's always been 'so last century'.
>
>> I'd run it every week or use Jay's idea. Mark's idea is
>> actually pretty tidy, but I just happen to hate hate hate
>> sentinel files. Almost every time I have a problem with
>> something that needs to be realiable (like nightly backups!)
>> it's because of sentinel files and it's usually unnecessary.
>
> I concur.
>
>> Even though one of my own most useful gadgets relies on them,
>> but only for 2 minutes each and it doesn't matter if they go
>> away or if fake ones show up or if permissions get fudged or
>> if the box powers off ungracefully etc... It's a self-cleaning
>> temp directory based on writing a timestamp file every minute
>> and deleting files older than the 2-minutes-ago timestamp file.
>> Worst case is after a reboot some files might live another 2
>> minutes longer than they should have.
>
> What do you do to keep the temp files that are supposed to be there
> until the ap using them exits?

It is not "/tmp" but a seperate dir which happens to be "/ptmp" which is 
also linked to ".../htdocs/ptmp"
Most uses of temp files are done in /tmp or PFTEMP rather than this /ptmp.

Mostly it is used for times when I want to throw something into the users 
browser but I don't want to give the world access to the place it came from 
by linking it in htdocs. So I generate a unique, meaningless name and copy 
it into ptmp and send a winstart command with the necessary url. The LAST 
thing I want to have to do in a case like that is try and guess how long to 
sit and wait before deleting the temp file, with the application frozen all 
that time or a cgi script hanging around or an fp process tying up a 
licence.
So I don't. I create the temp file, fire off the command to view it, and 
move right on and never think of the file again after that. I don't care if 
the users net connection allows the file to zip in instantly or if it takes 
almost the whole 2 minutes. If 2 minutes ever isn't long enough I can 
twiddle one variable in the script and make the lifetime whatever it needs 
to be. I originally used 4 min, toyed with the idea of letting things live a 
whole day.

Using "at" to delete things I don't want to wait for would thoroughly abuse 
the facility and not be as reliable. Same goes for something like "2mdel ... 
&" where 2mdel might be  sleep 120 ; rm "$@"

I recently realised it's handy for something else too. I have some processes 
that run in the background that aren't always easy to diagnose and only fail 
once in a while. A typical example is a cron job the periodically ftp 
downloads an edi file and then runs a series of fp reports to import it, or 
the other way around. The users will call up and think it's not working, or 
maybe it really isn't, and every time it could be any of several different 
stages that are all kinda easily messed up.

So I started having the various scripts & rreports write unique named log 
files to the temp dir and renaming their working files when they are done 
with them into the temp dir, except the original raw data which I rename and 
keep forever as evidence. They are unique so different jobs don't clobber 
each other, but all parts of a given job are similar.

So when there is a problem I have all this stuff like the stdout/stderr from 
the ftp command, screen output from rreport, etc all laid out nice to look 
at, and I have no pressing need to turn that debugging off since I'm not 
growing log files or roots mailbox.
So now instead of getting it all working and then turning off the various 
types of debugging, and then having a problem once in a while and being 
blind, the debugging is always on, and we can tell the customer in no 
uncertain terms that "their ftp server is down right now" or whatever 
instead of wasting time trying to fix code that's not broken. It's also 
easier to decipher these seperate files than single log files that many jobs 
write to.

2 minutes is a pretty short lifetime for that kind of stuff though, it'd be 
better if it hung around for a day, but it's not worth making another magic 
dir just for that.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani