cck@CUNIXC.CC.COLUMBIA.EDU (Charlie C. Kim) (07/27/88)
CAP Release 5.00 - PROBLEM REPORT: 0003 REPORT 0003 OS: any Revision: n/a Major local modifications: n/a Machine Type: n/a Date: 7/27/88 Reported by: Jim Madden, Univ. of Californa at San Diego Priority: HIGH Problem: Word crashes when saving a large file. An excellent problem description from Jim Madden is appended to the end. Diagnosis: Don't see how one could have ever saved files on Aufs volumes from Word. The problem was that the open file number table (OFNTBL) kept a copy of the file name that was not updated when a rename or move on the file was done. This would only be a problem when a program, e.g. Word, renamed the file while opened. Solution: It is not possible to simply use fstat since GetForkParms (or SetForkParms) needs a reference point so it can get to the finder information file (and so it can return the file name if requested) and there is no simple, clean method under unix for backtracking file names from file descriptors (checking inode fails in case of links, etc. I want my JFNS% (TOPS-20) sigh.). Simple solution is to patch things so that the file name in the OFN table gets updated. The REAL solution is to build an internal directory of file names. There are a number of places that this would help (finder information, enumeration, fork handling, etc.) and such would be highly desirable to support short file names (MS/PRO DOS), System V file names, etc. Unfortunately, the real solution requires a major rewrite of a number of modules. Patches for afpfork and afpfile follow. %%START OF PATCH%% *** /tmp/,RCSt1007888 Wed Jul 27 12:05:54 1988 --- afpfork.c Wed Jul 27 11:58:00 1988 *************** *** 126,131 } /* * OSErr FPGetForkParms(...) * * This call is used to retrieve parameters for a file associated with --- 126,159 ----- } /* + * This is a horrible hack that is necessary to ensure that renames + * get reflected back. Really, really, points to the need for internal + * directory of names.... Can't use fstat because file name is required + * to return some of the information (from finderinfo). Sigh... + * + */ + OFNFIXUP(oipdir, ofile, nipdir, nfile) + IDirP oipdir; + char *ofile; + IDirP nipdir; + char *nfile; + { + OFN *ofn; + if (!oinit) + return; + + for (ofn = OFNTBL; ofn < OFNTBL+MaxOFN; ofn++) + if (ofn->ofn_flgs & OF_INUSE) { + if (ofn->ofn_ipdir == oipdir && strcmp(ofn->ofn_fnam, ofile) == 0) { + ofn->ofn_ipdir = nipdir; /* remember new directory */ + strcpy(ofn->ofn_fnam, nfile); /* remember new file */ + } + } + return(0); + } + + + /* * OSErr FPGetForkParms(...) * * This call is used to retrieve parameters for a file associated with *************** *** 294,300 } } ! strcpy(ofn->ofn_fnam,file); fdp.fdp_fbitmap = ofk.ofk_bitmap; fdp.fdp_dbitmap = 0; --- 322,328 ----- } } ! strcpy(ofn->ofn_fnam,file); /* remember file name (UGH!!!!) */ fdp.fdp_fbitmap = ofk.ofk_bitmap; fdp.fdp_dbitmap = 0; *** /tmp/,RCSt1007888 Wed Jul 27 12:05:58 1988 --- afpfile.c Wed Jul 27 11:46:34 1988 *************** *** 208,215 printf("FPRename: different parent directory\n"); return(aeParamErr); } ! ! return(OSRename(ipdir,file,nfile)); } --- 208,218 ----- printf("FPRename: different parent directory\n"); return(aeParamErr); } ! err = OSRename(ipdir,file,nfile); ! if (err == noErr) { ! OFNFIXUP(ipdir, file, ipdir, nfile); ! } ! return(err); } *************** *** 299,305 } err = OSMove(ipdir,file,nidir,nf); ! if (err == noErr) /* if success */ VolModified(ivol); /* then volume modified */ return(err); } --- 302,309 ----- } err = OSMove(ipdir,file,nidir,nf); ! if (err == noErr) { /* if success */ ! OFNFIXUP(ipdir, file, nidir, nfile); VolModified(ivol); /* then volume modified */ } return(err); *************** *** 301,306 err = OSMove(ipdir,file,nidir,nf); if (err == noErr) /* if success */ VolModified(ivol); /* then volume modified */ return(err); } --- 305,311 ----- if (err == noErr) { /* if success */ OFNFIXUP(ipdir, file, nidir, nfile); VolModified(ivol); /* then volume modified */ + } return(err); } %%END OF PATCH%% ORIGINAL PROBLEM DESCRIPTION: Article 770 of comp.protocols.appletalk: Path: cunixc!columbia!rutgers!ucsd!net1!madden From: madden@net1.ucsd.edu (Jim Madden) Newsgroups: comp.protocols.appletalk Subject: CAP 50 AUFS problem Summary: MS Word file update crash Message-ID: <1057@ucsd.EDU> Date: 27 Jul 88 10:01:18 GMT Sender: news@ucsd.EDU Reply-To: madden@net1.UUCP (Jim Madden) Organization: UCSD Network Operations Group Lines: 31 While running the CAP 5.0 AUFS UNIX Appleshare emulation, we find that frequently when we ask MS WORD to save a file on an AUFS volume, WORD will crash with an odd address error (System Error 3) apparently generated by an odd value in the pc register. On at least one of our machines, the problem happens consistently if we copy Chapter 6 of the NCSA Telnet 2.2 documentation (or any other sizeable word document) to an AUFS volume, open it there with WORD 3.02, make a trivial change such as inserting a few blanks in the middle of a line, and then save the document (not using fast save). At about the 30% progress indication, WORD crashes with the odd address error. Further, the original Chapter6 document has been trashed, contrary to my understanding of how WORD organizes its saves to protect the original until the new file is in place. Does anyone have any insight into such a problem? For the record, the Mac involved is a Mac +, upgraded to 2 Mbytes, running System 6.0. This problem occurs both with and without Multifinder, and we think it happened before the ugrade to System 6.0. The Unix system is a Sun 2, running SunOS 3.2 and CAP 5.0. The Kinetics gateway connecting the Mac's Localtalk to the Sun's Ethernet is running KIP0688. Jim Madden UCSD Academic Network Operations END OF REPORT