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