RE: Solaris UNIX FM5.5.6 /tmp directory error

["Ede, Craig" <craig.ede@xxxxxxxxxxxxx>]

Peter, 

There is no aliasing going on with rm or rmdir. That should be behaving normally within the environment of the cron job script. It may be that our network printer list is so large that creating/deleting this file, 1.printerlist, creates a timing problem as a result of its size (8227 bytes).

I look into Thomas' suggestion on adding sleep commands at points where problems seem to be arising to allow for sub-tasks to complete.

I'll also be looking into the following suggestion from Richard Davies (I don't think he posted this):
=======begin embedded message=====================================
As you know, the fmbatch instance in the $FMHOME/bin directory
is simply a link to .wrapper. You can use this to put a
trap in .wrapper such that if $0 = fmbatch, then set and
export an envar (e.g. FMBATCH=yes ) which you can use
in the ./fminit/FMprinterlist shell script, something like:

<       #----------------------------------------------------------------
<       #--- START: Modification -- do not change this or line above
<       if [ "${FMBATCH}x" = yesx ]
<       then
<               if [ -d `/bin/dirname $1` -a `/bin/basename $1` = "1.printerlist" ]
<               then
<                       rm -rf `/bin/dirname $1`
<               fi
<               exit
<       fi
<       #--- END:   Modification -- do not change this or line below
<       #----------------------------------------------------------------

More refinements are possible, or even necessary. Putting the
trap in .wrapper makes sure 'normal' users are completely
unaffected. You could also set a special TMPDIR within the .wrapper
trap for all your fmbatch jobs. Apologies if you are way ahead of this,
and or I've not read your qestion properly ...

(I've cribbed some of the above from the Unix version of our
FM-based publishing product, which needs to play a few tricks
wrt printing, fmprindr.ps, etc.)

HTH.

Of course, shout if you have any questions & I'll try harder.

Regards,

Richard
==============end embedded message=========================================================

Thanks to all of you!

Craig
-----Original Message-----
From: Peter Gold [mailto:peter@highsoft.com]
Sent: Thursday, October 31, 2002 10:06 AM
To: Ede, Craig
Cc: framers@omsys.com
Subject: RE: Solaris UNIX FM5.5.6 /tmp directory error


Craig:

Have you tried the command that deletes the directory AND all files 
and subdirectories within? I'm not up on my UNIX, but I believe it's 
something like "rmdir -R." The "R" is for "recursive." You may also 
want to check your command aliases to see if rm or rmdir are aliased 
to rm -i, or rmdir -i (where "i" is for "interactive," which requires 
user confirmation. You may need to include an "unalias" statement in 
your script to avoid the interactive confirmation, then af the end of 
the script, innclude "alias" to reset the alias.

HTH

Regards,

Peter

At 9:48 AM -0600 10/31/02, Ede, Craig wrote:
>The error is caused by fmbatch itself during various FM calls 
>(opens, closes, etc.); so it is internal to FM operation. I tried to 
>express that by indicating that it is doing dynamic creation and 
>cleanup but failing in that in some instances.
>
>In the case of the multi-user environment it happens when maker is 
>called and attempts to create or remove .fm* dir(s) that are already 
>created by other users. I'm sure we could use TMPDIR to create user 
>specific dirs in /tmp or elsewhere to solve that problem, but the 
>cleanup issue is still there.
>
>The 1.printerlist file is an example of something FM is creating and 
>not cleaning up and then complaining about because it prevents the 
>deletion of the directory containing it. This is from the stdout log 
>of the script at the point where fmbatch is opening a MIF file to 
>convert to binary FM:
>
>Adobe Frame MIF file (my echo command)
>starting maker ... (fmbatch invokes maker)
>rmdir: directory "/tmp/.fmU2g3SUL.3DN": Directory not empty
>
>I don't think our shared license Unix installation is creating the 
>1.printerlist file via some customization. I expect that this is 
>(pretty much) a default FM installation. At any rate, my Unix admins 
>are not aware of anything special we are doing that would cause 
>this to behave differently.
>
>BTW: This is a Unix Solaris. (I've added this to the subject line.)
>
>Thanks.
>
>Craig

-- 
__________________________________________________
Peter Gold Applications Engineer
Adobe Certified Expert: FrameMaker/SGML, Acrobat, InDesign
WebWorks Publisher Certified Trainer

KnowHow ProServices  http://www.knowhowpro.com
Tech support: 650.691.0701 x266 Direct: 650.691.0701 x333
Outside SF Bay Area: 800.795.6066
FAX: 650.691.0995

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **