Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!cbosgd!osu-eddie!elwell%tut.cis.ohio-state.edu
From: elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP (Clayton Elwell)
Newsgroups: comp.protocols.appletalk
Subject: Re: Remote file representation
Message-ID: <4050@osu-eddie.UUCP>
Date: Thu, 27-Aug-87 11:27:12 EDT
Article-I.D.: osu-eddi.4050
Posted: Thu Aug 27 11:27:12 1987
Date-Received: Sat, 29-Aug-87 10:22:40 EDT
References: <8708250004.AA03964@beowulf.UCSD.EDU> <4035@osu-eddie.UUCP> <3725@sdcsvax.UCSD.EDU>
Sender: news@osu-eddie.UUCP
Reply-To: elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP (Clayton Elwell)
Organization: The Ohio State University, CIS Dept.
Lines: 64

In article <3725@sdcsvax.UCSD.EDU> jww@sdcsvax.UCSD.EDU (Joel West) writes:
>
>Once the data fork in AppleDouble is fully converted to the native
>format, translating on the fly seems the only way to go.  The main
>problem seems to be exactly the issue Clayton raises: which files
>should be translated and which should not?
>
>There are at least two solutions I can see:
>    1.	The remote file system has an (administrator-editable) list 
>	of file types that are translatable, presumably including TEXT
>	and EPSF but not WDBN or 'DVI '; or

Great minds think alike :-).  I have this list hardwired into the code,
since I am doing a little more than just CR-LF mapping (see below).

>    2.	The server always does TEXT (for upward compatibility)
>	and then there's another file bit somewhere added to
>	Mac files indicating that this is CR-delimited text,
>	thus allowing the server to know which ones are translated.

This is getting a little off of the subject, but I'll brind it up anyway.
There are two basic cases:  the host OS is looking at a file created
by a Mac program, and the Mac is looking at a file created by a host
program.  Here's how I do it now:

Case 1: Mac-created file.

If the file is of type TEXT, translate on the fly to host format as it
is being written out (Use AppleDouble).  Otherwise, check the type
against a magic list of types that the host understands.  If it's in
the list, use AppleDouble (but no translation on the data fork).  If
it's not, use AppleSingle.

Case 2: Host-created file.

This is where life gets interesting.  The basic idea is to leave the
file alone as much as possible.  The way I do this is to pretend the
file is in AppleDouble, but create the resource/info information on
the fly WITHOUT STORING IT BACK unless the Mac explicitly changes it.
The type of file is inferred by looking at the magic number and/or the
first K or so of the file.  The creator gets set to 'UNIX', and the file
type gets set as follows:

	ASCII text: 'TEXT'
		This includes PostScript and shell scripts.
		translation is done for these files.
	executable (with execute permission set): 'AOUT'
	executable (without execute permission set): 'UOBJ'
	archive: 'ARCV'
	DVI file: 'DVIF' (matches MacTeX from FTL Systems)

This list could be extended as far as is needed.  The server is also
set up so that there are entries for these types in the Dessktop
database, so they each pop up with an appropriate icon.


	
-=-

Clayton Elwell

Arpa/CSNet:	Elwell@Ohio-State.ARPA
UUCP:		...!cbosgd!osu-eddie!elwell
Voice:		(614) 292-6546