home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / bsd / 4789 < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.2 KB  |  112 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!mcsun!sunic!ugle.unit.no!lise.unit.no!arnej
  3. From: arnej@Lise.Unit.NO (Arne Henrik Juul)
  4. Subject: [386bsd] FIX: Truncating when appending over NFS 
  5. Message-ID: <1992Aug28.024229.22985@ugle.unit.no>
  6. Followup-To: comp.unix.bsd
  7. Sender: news@ugle.unit.no (NetNews Administrator)
  8. Reply-To: arnej@lise.unit.no
  9. Organization: Norwegian Institute of Technology
  10. Date: Fri, 28 Aug 92 02:42:29 GMT
  11. Lines: 99
  12.  
  13. Thanks to Ian Donaldson, I found - and fixed - the bug
  14. which causes files to be truncated when opened for append via
  15. NFS in certain configurations.
  16.  
  17. He said (some articles ago):
  18.  > 
  19.  > I fixed this exact bug in an ancient NFS port a few days ago (on a
  20.  > SVR3.2 machine actually).  The problem was that the NFS server wasn't
  21.  > interpreting the sattr information provided in the "NFS create" call
  22.  > properly.
  23.  > 
  24.  > One field of sattr is the file size.  When you do creat() of the above
  25.  > form, SunOS sends the file size attribute as -1 over the wire which
  26.  > should mean to the server "don't change the file size".  The server is
  27.  > probably ignoring this field and truncating the file unconditionally
  28.  > (at least thats what the server I worked on did).
  29.  > 
  30.  > The fix was trivial... just recognize the size attribute and if -1,
  31.  > leave the file size alone, otherwise truncate to the specified value.
  32.  > 
  33.  > Ian D
  34.  
  35. And this was exactly what was wrong. The file was always truncated if
  36. it existed. The reason why it only happens when used from certain
  37. NFS clients, is that some clients does not do a NFS create request at
  38. all if the file already exists.
  39.  
  40. So everybody who are just waiting to run their 386bsd machines as file
  41. servers, this is your patch :-)
  42.  
  43. *** nfs_serv.c.orig    Fri Aug 28 04:34:35 1992
  44. --- nfs_serv.c    Fri Aug 28 04:40:29 1992
  45. ***************
  46. *** 550,556 ****
  47.   
  48.   /*
  49.    * nfs create service
  50. !  * now does a truncate to 0 length via. setattr if it already exists
  51.    */
  52.   nfsrv_create(mrep, md, dpos, cred, xid, mrq, repstat, p)
  53.       struct mbuf *mrep, *md, **mrq;
  54. --- 550,557 ----
  55.   
  56.   /*
  57.    * nfs create service
  58. !  * if it already exists, just set length
  59. !  * do NOT truncate unconditionally !
  60.    */
  61.   nfsrv_create(mrep, md, dpos, cred, xid, mrq, repstat, p)
  62.       struct mbuf *mrep, *md, **mrq;
  63. ***************
  64. *** 588,595 ****
  65.       VATTR_NULL(vap);
  66.       nfsm_disect(tl, u_long *, NFSX_SATTR);
  67.       /*
  68. !      * Iff doesn't exist, create it
  69. !      * otherwise just truncate to 0 length
  70.        *   should I set the mode too ??
  71.        */
  72.       if (nd.ni_vp == NULL) {
  73. --- 589,596 ----
  74.       VATTR_NULL(vap);
  75.       nfsm_disect(tl, u_long *, NFSX_SATTR);
  76.       /*
  77. !      * If it doesn't exist, create it
  78. !      * otherwise just set length from attributes
  79.        *   should I set the mode too ??
  80.        */
  81.       if (nd.ni_vp == NULL) {
  82. ***************
  83. *** 654,660 ****
  84.           else
  85.               vput(nd.ni_dvp);
  86.           VOP_ABORTOP(&nd);
  87. !         vap->va_size = 0;
  88.           if (error = VOP_SETATTR(vp, vap, cred, p)) {
  89.               vput(vp);
  90.               nfsm_reply(0);
  91. --- 655,661 ----
  92.           else
  93.               vput(nd.ni_dvp);
  94.           VOP_ABORTOP(&nd);
  95. !         vap->va_size = fxdr_unsigned(long, *(tl+3));
  96.           if (error = VOP_SETATTR(vp, vap, cred, p)) {
  97.               vput(vp);
  98.               nfsm_reply(0);
  99.  
  100. --
  101. Arne H. Juul  --  arnej@lise.unit.no  --  University of Trondheim, Norway
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.