home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text5379.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  2.1 KB
  1. Received: from BBN.COM (BBN.COM [128.89.0.122]) by nacm.com (8.6.10/8.6.9) with SMTP id MAA09047 for <executor@nacm.com>; Thu, 12 Oct 1995 12:41:49 -0700
  2. Received: from archetype.prospect.com by BBN.COM id aa18255; 12 Oct 95 15:21 EDT
  3. Received: from sol.atype.com by atype.com (NX5.67d/NX3.0M)
  4.     id AA25136; Thu, 12 Oct 95 15:21:25 -0400
  5. Received: from titan.atype.com by  sol.atype.com  (NX5.67d/NeXT-2.0)
  6.     id AA09602; Thu, 12 Oct 95 15:21:24 -0400
  7. From: deh@atype.com (David E. Hollingsworth)
  8. Message-Id: <9510121921.AA09602@ sol.atype.com >
  9. Received: by titan.atype.com (NX5.67d/NX3.0X)
  10.     id AA04518; Thu, 12 Oct 95 15:21:23 -0400
  11. Date: Thu, 12 Oct 95 15:21:23 -0400
  12. To: Brad Midgley <junkmail@pht.com>
  13. Cc: executor@nacm.com, brad@pht.com
  14. In-Reply-To: Brad Midgley's message of Thu, 12 Oct 1995 08:32:48 -0600 (MDT)
  15. Subject: Re: netatalk-style resource forks?  (please? :)
  16. References: <Pine.LNX.3.91.951012081238.1368B-100000@exodus.pht.com>
  17. Sender: owner-paper@nacm.com
  18. Precedence: bulk
  19.  
  20.  
  21. Since ARDI's going full throttle on 2.0, I doubt that this is really going to
  22. be an issue for them for quite some time, but...
  23.  
  24. In article <Pine.LNX.3.91.951012081238.1368B-100000@exodus.pht.com> Brad Midgley <junkmail@pht.com> writes:
  25. >   I'm not sure if this has come up yet, but since executor doesn't have
  26. >   network support, could it at least support the netatalk method of keeping
  27. >   resource forks in a .AppleDouble directory?  (how about a non-defaulted 
  28. >   command-line option?)
  29.  
  30. Of course, CAP aufs uses .resource directories, Helios EtherShare and IPT
  31. uShare use .rsrc directories, Xinet KA-Share uses .HSResource directories, and
  32. Pacer PacerShare uses afp_resource directories.
  33.  
  34. There are corresponding differences for desktop representation.  Many of these
  35. systems also appear to have files or directories for storing finder
  36. information.  Fun, eh?
  37.  
  38. ARDI's got good folks.  If handling foreign formats ever becomes an important
  39. issue, I'm sure they'll design something extensible and clean, even if only a
  40. subset of the systems mentioned above are specifically supported.
  41.  
  42. David Hollingsworth
  43.  
  44.