home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / nfs / 2708 < prev    next >
Encoding:
Text File  |  1992-11-06  |  2.7 KB  |  56 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!utcsri!torn!maccs!beame
  3. From: beame@maccs.dcss.mcmaster.ca (Carl Beame)
  4. Subject: Re: Apparent bug with DOS 5 XCOPY.EXE and PC-NFS
  5. Message-ID: <1992Nov6.042708.27898@maccs.dcss.mcmaster.ca>
  6. Keywords: xcopy dos nfs
  7. Organization: McMaster University, Hamilton, Ontario, Canada.
  8. References: <8580@lee.SEAS.UCLA.EDU> <1992Nov5.045412.20596@kirk.bu.oz.au>
  9. Date: Fri, 6 Nov 1992 04:27:08 GMT
  10. Lines: 44
  11.  
  12. In article <1992Nov5.045412.20596@kirk.bu.oz.au> bambi@bu.oz.au (David J. Hughes) writes:
  13. >roff@felon.icsl.ucla.edu (David Roff) writes:
  14. >
  15. >>We've discovered an apparent bug involving the interaction of DOS 5.0's 
  16. >>XCOPY command and PC-NFS.  When running a batch file containing several
  17. >>XCOPY statements in succession, copying files from a local hard disk to
  18. >>a network drive, DOS will occasionally report it can't find selected files.
  19. >>Issuing the same XCOPY statements via command line, however, works fine.
  20. >>Moreover, using COPY instead also works.  Is this a well known bug?  Any
  21. >>fixes?
  22. >
  23. >If you are using XCOPY to do large recursive copies then you will often
  24. >run into problems (not sure if this is the case as the original posting
  25. >doesn't contain many details).  The cause of this is the redirector used
  26. >to access a remote volume often runs out of internal buffers if the
  27. >recursion is too deep.
  28. >
  29.  
  30.     Basically, the problem has to due with the DOS Findfirst/Findnext
  31. functions and their mapping to NFS calls. The firstfirst function returns
  32. to the users a structure which contains the filename and 21 bytes of
  33. reserved data which define where a findnext will start in the directory
  34. search. The findnext can be called at ANY point in the future (immediatly
  35. or maybe in an hour or so ... :-) ). To perform a "findnext", the NFS client
  36. must pass to the NFS server, a 32 byte directory handle and a 4 byte "cookie"
  37. as well as have stored the filename matching information passed in the findfirst
  38. call. This information does not fit the 21 byte DOS reserved area and
  39. therefore the client NFS must allocate an internal buffer to place this
  40. information and put a pointer to it in the 21 byte DOS structure.
  41.  
  42.     An XCOPY will usually have 1 outstanding findnext for every level
  43. of directory. Under DOS 5.0 there can be 32 directory levels. In our
  44. NFS (BWNFS) several versions ago, we HAD a problem which a program which
  45. used the C stat() call on all files. The stat() call uses Findfirst with out
  46. any findnexts.  
  47.  
  48.     After all this, I don't think this is the problem with copying files
  49. from the PC to the server as XCOPY does many findfirst/findnext on the
  50. destination of the copy. The finds are done on the source.
  51.  
  52. Carl Beame
  53. Beame & Whiteside Software
  54. tech@bws.com
  55.  
  56.