🚀 go-pugleaf

>>I had terrible experience with Interleaf's desktop technical publishing
>>software running on a SUN. It has a dangerous bug. I have several
>>files striked by this bug and cannot be recovered. The main symptom
>>being an "unrecognizable record" when loading the file. Has anyone
>>besides me got bitten by this bug?

I've been trying to find the original posting of this bug, but the
Comp.text.desktop archive-server seems to be holding out on me :-(.

So, based on the information available ("unrecognizable record") I have
two suggestions.  Neither can really be called bugs, but they can
be termed as dangerous system habits.

The "unrecognizable record" loader message is most frequently seen when
an attempt is made to load a file so corrupted that it's form makes no
sense to the loader.  Not too many things, short of malignant hardware
failure can cause this, but the following two practices have the 
potential.  Its certainly worth checking for them.


1. Soft mounted read/write NFS file systems

	For some reason, Sun does not make the "rw" (read/write) and "soft"
	(soft mount) options of the "mount" command mutually exclusive.
	The advantage of soft-mounting is that a process will not hang
	indefinitely attempting I/O on an inactive or crashed NFS server.
	The disadvantage is that a write operation can fail *SILENTLY*,
	leaving a corrupted file on the NFS server.  It is for this 
	reason that Sun strongly suggests that all r/w NFS mounts be
	hard mounts.

	We have run into cases where people have configured systems to 
	do soft-mounts only, in order to avoid one system freezing up
	waiting for another to either reboot or reconnect.  This creates
	a potential, particularly during heavy system use, for corrupt
	files to be created.  

	Solution: Make sure all NFS soft mounts are read-only.


2. Multiple editors editing the same file.

	There have been cases where files have been edited by two
	editing processes, either by the same user opening the file twice
	(the original & the copy-linked version) or by two users
	using the same desktop.  If both editor's attempt to
	write changes to the file, the result will most likely be
	a corrupted file.

	There is a warning popup displayed when a file currently being
	edited is opened for editing.  This warning can be overridden,
	and this is OK if you have the permission of the person currently
	editing the file (which could be yourself) and you don't intend
	to change the file.  However, you cannot expect an editor to 
	reliably update a file being simultaneously changed by a 
	separate editor process.

	Solution: Check with the users and make sure they all know the
		  importance of this warning:

                              Document is locked
     It was opened at Fri Oct 10 17:45:48 1986, by user "tim" on node jasper.
	       Do not override the lock without tim's permission.
		      Do you wish to override the lock?
			       Yes	No

I hope this helps.  

Regards,
Dave Benjamin

...!eddie.mit.edu!ileaf!dbjag	Dave Benjamin, Interleaf, Cambridge, Ma
    ...!sun!sunne!ileaf!dbjag	(617) 577-9800 



----------------------------------------
Submissions to: desktop@plaid.sun.com
Administrivia to: desktop-request@plaid.sun.com
UUCP: {amdahl,decwrl,hplabs,ihnp4}!sun!plaid!desktop{-request}
Archives can be gotten from the archive-server.
To get information on the archive-server, send mail to:
archive-server@plaid.sun.com -or- sun!plaid!archive-server
with a subject line of help