aw0g+@ANDREW.CMU.EDU.UUCP (08/31/87)
[this is the second and last delayed message. Aaron Wohl (aw0g@andrew)] Date: 25 Aug 87 21:15:55 GMT From: elwell%tut.cis.ohio-state.edu@OHIO-STATE.ARPA (Clayton Elwell) Organization: The Ohio State University, CIS Dept. Subject: Re: Remote file representation Message-Id: <4035@osu-eddie.UUCP> References: <8708250004.AA03964@beowulf.UCSD.EDU> Sender: info-appletalk-request@andrew.cmu.edu To: info-appletalk@andrew.cmu.edu In article <8708250004.AA03964@beowulf.UCSD.EDU> joel%beowulf@palomar.UUCP writes: >[...] > >2. The AppleDouble format does not address one important issue. > The data fork of a Macintosh file is not normally readable > by another file system. To contrast it with three with > which I am familiar: > *) Mac: CR at end of each record > A) UNIX: LF at end of each record > B) MS-DOS: CR-LF at end of each record > C) VMS: preceeded by a binary length > If the data fork is to be readable, then it must be translated > into the native format, and its original format saved. > > I think there needs to be a line-translation entry to indicate > the original line delimiter so it can be restored from the > native format We talked about this issue at the file representation session before Macworld Expo. The problem is that there are text files, and there are other files (I, for example, routinely move TeX DVI files back and forth betweeen my Mac and our Pyramid 98x). Unfortunately, it's not as simple as putting in a delimiter specification (see below for my solution (hack?)). The only way I could see to do this generally would be to define some sort of translation script language, but this seems to fall outside of the file format itself. > Record Delim 9 1 or more delimiter characters > For example, a Mac file stored on MS-DOS would be stored with CR-LF > delimiters but with Record Delim = $0D. (on VMS, you could use > RAT=CR, which would be an exact copy of the Mac data fork). > > The AFP or some other protocol also needs either record- > at-a-time i/o or a "What is this file's delimiter" query, so > that a Mac program can read a file directly from a UNIX > server (in LF-delimited form) and vice versa. Coming from the point of view of writing a server, I translate on the fly between native text format and Mac text format. This does assume that you're not going to seek around in text files randomly (although in my case even this works, since my host system is UNIX). If you're using it for archival purposes, a little utility to extract or replace a text file wouldn't be hard, and is usable in practice (it's what I've been doing for the last 6 months or so). The combination of the file system identifier and file type should be enough information. >3. The use of the icon ought to be better defined, or this will > vary all over the place. For example, the spec ought to say > something like: > Applications normally include their icons, but documents > do not. > (or maybe all always include their icon) I don't see how this is really a problem. Some things will have icons, and some won't. In a heterogeneous environment, I don't see a simple way to avoid that. You will fairly often have documents isolated from their associated applications (if any), but you still want them to have appropriate icons. Then again, you don't want to worry about icons for MS-DOS files. >4. Again, their ought to be file naming guidelines for mapping > (recommendations for consistency, not absolute rules) so that > there is similarity between various systems. For example, > A) Case is stripped on systems that don't support case, so > Foo.C becomes FOO.C > B) Spaces are mapped to "_" if available, otherwise to > another available non-alphanumeric special character. > C) Standard mappings for Macintosh extended characters. > For example, all accented letters are stripped to their > IUMagString equivalents, > `e becomes e > c, becomes c > etc. Characters that have no equivalent are removed > ((R), TM, (C), etc.) since they are likely to be noise > characters. This is getting pretty file system dependent, which as I understand it was why it was left open. For most systems, a simple scheme can be put together based on the naming restrictions. Since the native (Macintosh) name is stored in the file, you don't really lose anything. Once again, this is more of an issue of application than formatting. >5. Presumably if a new file is being created in this directory > and it truncates to an existing AppleSingle or AppleDouble > file, the program will check for the actual name and, if > different, choose a new truncated name to save the file. > > For example, > > 'AntiDisestablish Text' and 'AntiDisestablish Text 2' > might be stored as > ANTIDIST. and ANTIDIS2. > on an MS-DOS system. See above. >This is obviously an area where a standard is sorely needed, >and as an A/UX user, I hope A/UX 1.0 implements the final >AppleDouble proposal. > > Joel West > Palomar Software, Inc., POB 2635, Vista, CA 92083 > joel%palomar.uucp@beowulf.ucsd.edu > ihnp4!crash!palomar!joel joel@palomar.cts.com > AppleLink: D0619 MCI: Palomar Remember that this is a draft, and thus doesn't have all of the examples and recommendations that we are used to in Apple docs (final ones, anyway :-)). I've been playing with AppleDouble in my server, and it seems to be quite usable. It's sure a lot better than, say, MacBinary... I second the motion to put it in the A/UX toolbox (as if they needed more things to work on :-)). -=- Clayton Elwell Arpa/CSNet: Elwell@Ohio-State.ARPA UUCP: ...!cbosgd!osu-eddie!elwell Voice: (614) 292-6546