home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / networks / tcpip / multinet / 2150 < prev    next >
Encoding:
Text File  |  1992-09-14  |  2.6 KB  |  52 lines
  1. X-Gateway-Source-Info: INTERNET
  2. Path: sparky!uunet!usc!news.service.uci.edu!unogate!mvb.saic.com!tgv.com!info-multinet
  3. Date: 14 SEP 92 22:16:40 GMT
  4. Newsgroups: vmsnet.networks.tcp-ip.multinet
  5. X-Return-path: <info-multinet-relay@TGV.COM>
  6. X-RFC822-From:     adelman (Kenneth Adelman) @ TGV.COM
  7. From: adelman@TGV.COM
  8. Subject:  Re: Logical disk on Sun for microVAX ??
  9. Organization: The INFO-MULTINET Community
  10. Message-ID: <2C200ADE14SEP92221640@TGV.COM>
  11. Nntp-Posting-Host: Mvb.Saic.Com
  12. Lines: 38
  13.  
  14. > At our site we have a DEC MicrovaxII (running VAX/VMS 5.5, MultiNet 3.1) linked over ethernet to a Sun SPARCserver 4/490 (running SUNOS 4.1.1). We are having trouble with Multinet working between these machines to our specific requirements.
  15.  
  16. > What we require is to have a directory mounted from the Sun server onto the Microvax using NFS Client. This directory will not be used from the Sun side (unix), but will be used exclusively as another "device" on the Microvax.
  17.  
  18. > We have mounted the SUN directory with the following command:
  19. > NFSMOUNT/SEMANT=NOSTR/VOL=R76DISK cruiser::"/usr6/r76disk" R76DISK
  20.  
  21. > There are some differences in behaviour between r76disk and a physical Vax disk, which we are trying to resolve.
  22.  
  23. > 1.  files copied or restored from a backup to r76disk lose their creation dates.
  24.  
  25.     NFS doesn't have a concept of a true creation date.  Our NFS
  26. Client displays as the creation date of a file the UNIX (or "NFS")
  27. "ctime", which is really the time the inode was modified.
  28. Unfortunately, the NFS protocol gives no way of setting the ctime in a
  29. create or set attribute request, so we're completely at the mercy of
  30. the NFS Server to chose the creation time.  Any request to change the
  31. creation time through the NFS Client is a no-op.
  32.  
  33. > 2.  files restored from backups to r76disk get execute permission
  34. > for system added to their file protection.
  35.  
  36.     NFS doesn't have a concept of system access. As such we display the
  37. system access as RWED. Any request to set the system access bits are
  38. ignored. The same is true of the "D" bit; "D" is not stored in the
  39. NFS server but rather displayed the same as the "W" bit.
  40.  
  41. > 3.  files copied to r76disk always get default file permissions
  42. > regardless of what file permissions they had to start with.
  43.  
  44.     What is happening here is that the create request comes across
  45. from RMS without any explicit permission setting in it, which results
  46. in us using the process default protections. If you do an explicit
  47. CREATE/PROTECTION= you'll get those protections. The F11B rules of
  48. default protections based on the protection of the directory, etc,
  49. don't apply over NFS.
  50.  
  51.                                 Ken
  52.