Subject: Re: [netatalk-admins] 8.1
From: a sun (asun@zoology.washington.edu)
Date: Wed Jan 21 1998 - 17:19:54 EST
My bet is, however, that long file names on AFP volumes will require an
updated version of AFP because the current AFP network requests probably
don't have room for long file names, either. That probably wouldn't be
very hard to add to netatalk, but until it happens, Macs (even if they DO
support long file names) will continue to get their short names.
there are only a handleful of places in the netatalk code that
actually check against 31 character names. the length of the name
actually gets encoded in each filename, so it shouldn't be difficult
to modify things to work for arbitrary filename lengths. netatalk
really just needs two things to deal with an as-yet-unreleased
really-long-filename-aware finder:
1) unicode support
2) beefed up path type support.
the way netatalk is designed, #1 just entails rethinking the utom and
mtou functions a little with unicode tables. don't the samba patches
do that? we might have to think about wide character support a little
as i think only the newer os's have c libraries with that kind of
support.
the easiest way of doing #2 would be to use the path type in cnames as
a means of just restricting file name length and not worry about
converting between different lengths.
i.e., a path type of 1 allows access to only 12-character filenames, 2
allows access to 31-character filenames, and whatever gets decided for
255-character filenames (i'm guessing a path type of 3) allows access
to those. currently, netatalk only allows a path type of 2, making the
windows weenies unhappy. the cost of doing this, of course, is
slightly slower directory lookups due to the need to check filename
lengths.
the ugly and difficult way of doing this would be to map files between
each of the three filename length spaces. i actually don't think
that's worth the pain it would entail.
-a
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:30:30 EST