home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text5504.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  4.0 KB
  1. Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id MAA29165 for <executor@nacm.com>; Mon, 16 Oct 1995 12:40:55 -0700
  2. Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id NAA20793; Mon, 16 Oct 1995 13:40:48 -0600
  3. Received: from beaut.ardi.com by mailhost  with smtp
  4.     (nextstep Smail3.1.29.0 #11) id m0t4vM1-000YcBC; Mon, 16 Oct 95 13:37 MDT
  5. Received: by beaut.ardi.com (linux Smail3.1.28.1 #5)
  6.     id m0t4vLz-00002QC; Mon, 16 Oct 95 13:37 MDT
  7. Message-Id: <m0t4vLz-00002QC@beaut.ardi.com>
  8. Date: Mon, 16 Oct 95 13:37 MDT
  9. From: ctm@ardi.com (Clifford T. Matthews)
  10. To: Brad Midgley <brad@pht.com>
  11. Cc: "David E. Hollingsworth" <deh@atype.com>, executor@nacm.com
  12. Subject: Re: netatalk-style resource forks? (please? :)
  13. In-Reply-To: <Pine.LNX.3.91.951016091032.28145B-100000@exodus.pht.com>
  14. References: <9510121921.AA09602@ sol.atype.com >
  15.     <Pine.LNX.3.91.951016091032.28145B-100000@exodus.pht.com>
  16. Sender: owner-paper@nacm.com
  17. Precedence: bulk
  18.  
  19. >>>>> "Brad" == Brad Midgley <brad@pht.com> writes:
  20.  
  21.     Brad> hello...  desktop representation is out of the question (too
  22.     Brad> different for everybody), but executor should at least put
  23.     Brad> its resource forks in a subdirectory without mangling the
  24.     Brad> name. Other schemes could depend on softlinks to that
  25.     Brad> directory.  (would only have to be fixed up when folders
  26.     Brad> were created) Mangling the name in the current directory is
  27.     Brad> ugly.
  28.  
  29. The problem is that the Apple Double spec. is an incredibly bad
  30. specification, but rather than go our own way, we adhere to it.  There
  31. are actually a few other Mac connectivity tools that adhere to the
  32. spec. as written and Executor will interact with them correctly (off
  33. the top of my head I think InterCon has a product that does this and I
  34. think Paul Hargrove's HFS Linux filesystem can create in-spec
  35. AppleDouble names).
  36.  
  37.     Brad> The easy road to get executor to deal with a network on a
  38.     Brad> netatalk-supported host will be to depend on kernel DDP and
  39.     Brad> link in the netatalk libs.  so why not use a compatible
  40.     Brad> naming scheme now and avoid the headache later?
  41.  
  42. Yes and no.  We could make a very quick hack to support the netatalk
  43. style names and have considered doing it at least for our own internal
  44. use (Cotton uses netatalk) but have so far resisted.  I think Cotton
  45. plans on writing a little script that will recursively convert a
  46. directory and its children in either direction between the netatalk
  47. naming convention to the AppleDouble naming convention.  That will be
  48. useful to him and perhaps to many of you out there as well.
  49.  
  50. Internally Executor and netatalk both use the AppleDouble file format;
  51. it's only the naming where they deviate from the spec.
  52.  
  53.     Brad> btw, ardi's bugs/feedback page is broken.  anyone there?
  54.  
  55. Send e-mail to "webmaster@ardi.com" and cc it to "bugs@ardi.com" with
  56. more detail and we'll get it fixed ASAP.  We have received a few bug
  57. reports here and there so we assumed it was working.
  58.  
  59.     Brad> On Thu, 12 Oct 1995, David E. Hollingsworth wrote:
  60.  
  61.     >> In article
  62.     >> <Pine.LNX.3.91.951012081238.1368B-100000@exodus.pht.com> Brad
  63.     >> Midgley <junkmail@pht.com> writes: > I'm not sure if this has
  64.     >> come up yet, but since executor doesn't have > network support,
  65.     >> could it at least support the netatalk method of keeping >
  66.     >> resource forks in a .AppleDouble directory?  (how about a
  67.     >> non-defaulted > command-line option?)
  68.     >> 
  69.     >> Of course, CAP aufs uses .resource directories, Helios
  70.     >> EtherShare and IPT uShare use .rsrc directories, Xinet KA-Share
  71.     >> uses .HSResource directories, and Pacer PacerShare uses
  72.     >> afp_resource directories.
  73.     >> 
  74.     >> There are corresponding differences for desktop representation.
  75.     >> Many of these systems also appear to have files or directories
  76.     >> for storing finder information.  Fun, eh?
  77.  
  78.     Brad> brad@pht.com
  79.  
  80.