[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: "framers" <framers@xxxxxxxxx>
Subject: RE: What does this Frame 5.5.6 error message mean?
From: Ed Treijs <etreijs@xxxxxxxxxxxxxxxx>
Date: Tue, 5 Mar 2002 12:00:08 -0500
Sender: owner-framers@xxxxxxxxx
[Quote:] > one additional thing I'd check is the system clock settings on the > systems - FM will generate the message you describe if the time stamps > on the files differ "enough" to make it think that the file has been > changed outside of its control. In particular, I suppose we'd see the problem if the UNIX system (NFS? samba?) time runs ahead of the NT time? Thanks; if we have problems we can look at the time on our NT boxes. I'll see if our IT people can tell us which UNIX clock is the one we should look at--the samba server maybe? We have bazillions of UNIX machines, and all our home directories are on a few big file servers that don't allow user logins. > The "file has an odd suffix" message is caused by how FM saves files - > it creates a dummy file with an artificial suffix, then once that is > successfully saved to disk it renames it over the original. > (rationale: > saving can be slow, especially across a network, so this protects from > errors corrupting the original copy; but renaming is essentially > instantaneous) If it can't replace the original, the message is > displayed. When we look in the UNIX directory, we unfortunately don't see anything like "mydoc.fm.572a2". Is the temp file hidden in some peculiar way? If it isn't, the error happens during the renaming process. It must happen late enough that both: --the dummy file no longer exists --the original file no longer exists because we don't have the original file, the dummy file, and often enough no .backup file! That's painful when you've lost a whole chunk of work, AND have to find a backup somewhere, real quick. > These all can be triggered by access control issues on the working > directory, especially in later versions of Solaris which > implement ACL's > in addition to "simple" unix permissions. Be sure that all the users > have the necessary create/modify/delete rights on the directories in > question. This problem occurs sporadically. Maybe there's a mechanism I am missing, but user IDs and UNIX groups shouldn't be changing randomly! Thanks again for the help. I've sent it along to our IT people, and I'll go and follow up shortly. ....Ed ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **