RE: Solaris UNIX FM5.5.6 /tmp directory error

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

Well, I can do that after the fact (or once they exist, before the fact). But that doesn't stop the error from happening the next time the script runs. It's really a problem of why frame isn't able to clean up after itself (I don't create these directories, it does.)

I'm wondering if it is a timing issue, where some sub-process isn't completing before the rmdir caused by fmbatch invoking and closing maker sessions completes.

Thanks.
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.   **