news@sun.uucp (news) (05/03/88)
>>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