home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / appletal / 3224 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.5 KB  |  49 lines
  1. Newsgroups: comp.protocols.appletalk
  2. Path: sparky!uunet!news.mtholyoke.edu!jbotz
  3. From: jbotz@mtholyoke.edu (Jurgen Botz)
  4. Subject: Re: CAP6.1 and Publish and Subscribe
  5. Message-ID: <BtpwEx.GE8@mtholyoke.edu>
  6. Sender: news@mtholyoke.edu (USENET News System)
  7. Organization: Mount Holyoke College
  8. References: <SANDY.92Aug28130057@beeker.cs.umass.edu>
  9. Date: Fri, 28 Aug 1992 23:40:08 GMT
  10. Lines: 37
  11.  
  12. In article <SANDY.92Aug28130057@beeker.cs.umass.edu> wise@cs.umass.edu writes:
  13. >We are running CAP6.1 on a DECstation 5000/Ultrix 4.2 and have
  14.  
  15. CAP6.1?  Last I checked the highest version was 6.0pl125.
  16.  
  17. >found that edition files are unusable if placed on server volumes.
  18. >Attempting to subscribe to or view the edition results in an error.
  19.                                                            ~~~~~~~~
  20. What was the error?  I just tried it, and I did _not_ get an error...
  21. rather, it failed silently.  I.e., I managed to subscribe to an edition
  22. on a CAP volume, but the edition was empty.  However, when I tried the
  23. same thing with both the publisher and the subscriber on the same
  24. machine (but the edition still on a CAP volume), it worked fine.
  25.  
  26. This leads me to believe that the problem is with the fact that if
  27. the Publisher and Subscriber are on different systems, they are referring
  28. to the directory which contains the edition with different dirIDs.
  29.  
  30. The failure of CAP to conform to the AFP requirement that dirIDs be
  31. constant and unique throughout the lifetime of the volume (filesystem)
  32. appears to be breaking several recent features of the Mac OS: definitely
  33. aliases, probably publish & subscribe.  I would say it is time to rethink
  34. this functionality... anybody working on that already?  I've browsed the
  35. code, and it sure isn't going to be trivial, no matter what scheme is
  36. used.  I'm tempted actually to go ahead a simply use inodes, thereby
  37. complying with the "constant" requirement, but probably breaking the
  38. "unique throughout lifetime" requirement even more thoroughly.  Still,
  39. I think this might not actually be so bad, since inodes are only re-used
  40. after a file is removed anyway, so the only time that the Mac should get
  41. a dirID that no longer points to the right directory is when the right
  42. directory no longer exists.  Given that, what is the worst thing that
  43. can happen?
  44. --
  45. Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
  46. Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
  47. Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
  48. South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
  49.