[comp.protocols.appletalk] Special chars in Gatorbox Filenames

km@mathcs.emory.edu (Ken Mandelberg) (05/31/90)

I notice that at least in the (year old) release of the Gatorbox
software we are running, there is no provision for handling Macintosh
filenames containing characters that cannot be embedded in Unix
filenames, for example "/".

The tech manual says that this will be handled in later releases. Has
this happened yet?

Is there a standard for handling this? Certainly it would not be hard
to develop an "escape" mechanism for special characters. However, one
would want the same mechanism used by the Gatorbox, and say A/UX, so
that one set of files could be distributed to both by NFS.
-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: (404) 727-7963

acs11059@uxa.cso.uiuc.edu (06/01/90)

Get a newer release of the GatorBox software. The version we are running at
Publication Services has a provision for an editable list of characters that
the Gatorbox will not allow in filenames. (So you can keep people on macs from
making filenames with *()$/\ and other such characters in them....)


					Aaron Sawdey
					aaron@pubserv.com

pclark@SRC.Honeywell.COM (Peter Clark) (06/01/90)

There is a way to deal with this:
I'm not sure where exactly in the GatorShare software you find this, but one
of the configuration options (under the Advanced Options dialog box) lets you
set all sorts of things that haven't been implemented yet (such as secure NFS
& others), as well as timeouts & *characters to refuse*.

However, refuse is exactly what it does- someone trying to copy a file with
those characters in the name will get a 'disk error' dialog, and the file
won't be copied. No other explanation! Which makes some trouble for the
administrators.

Hopefully, there'll be a fix for this soon... but it hasn't happened yet (I'm
using release 1.4.1).

Out of curiosity, how does AUFS handle these tricky file names?

Pete Clark
Honeywell SRC
Minneapolis, Mn
pclark@src.honeywell.com