Subject: [netatalk-admins] 8.1

From: John Ostrowick <[email-masked]>
Date: Wed, 21 Jan 1998 09:47:30 +0200 (SAT)

anyone here tried to see what happens to netatalk when it talks to os8.1
with its hfs+ ? eg., file name length...?

____________________________________________________________
John Ostrowick
[email-masked], +27 11 716-3783
Computer Science Department, University of the Witwatersrand   
Web site, ftp site and listserv all available at: 
http://macaroni.cs.wits.ac.za/

---

From: Rob Newberry <[email-masked]>
Date: Wed, 21 Jan 1998 08:39:02 -0500 (EST)

> with its hfs+ ? eg., file name length...?

Although HFS+ does SUPPORT long file names (255 chars) in the filesystem,
the MacOS itself does NOT support this feature yet.  So currently, there
is no way to get/set a filename longer than 31 chars using the MacOS.
Since no other OS reads/writes HFS+ volumes at this point, well, you can
probably see where I'm going with this.

Apple has said that Rhapsody will support HFS+, and Rhapsody already
supports 255-character filenames, so when that happens, we will see.
Apple has also said that support for the long file name feature of HFS+
will be in future MacOS releases.  At the earliest, that would be Allegro,
which is scheduled for mid year.  Keep in mind, however, that the changes
will require changes in applications as well -- the current APIs use
pascal strings (i.e., length byte at beginning), which limit you to
255-char full PATH names (i.e., not just filenames); and most MacOS
programs use FSSpec records, which only have 63-characters of space for
filenames.  Clearly Apple will need to deliver a name-mangler similar to 
Microsoft's Win95/NT support for FAT volumes.

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.

(I think that's the case -- a developer can correct me if I'm plain wrong
-- I haven't looked at the code in a while.)

So, the short answer is, for all practical purposes, HFS+ doesn't do
anything for long file names yet, because the OS doesn't support the
feature in the filesystem yet.  And therefore, there is no impact
whatsoever on AFP network volumes.

Rob

---

From: Georg Schwarz <[email-masked]>
Date: Wed, 21 Jan 1998 15:52:17 +0100 (MET)

> supports 255-character filenames, so when that happens, we will see.

with Rhapsody you won't need Netatalk, you'll use NFS I'd guess.

-- 
Georg Schwarz                             [email-masked]
Institut für Theoretische Physik    Tel. +49 30 314-24254, FAX -21130
Technische Universität Berlin          http://home.pages.de/~schwarz/
Sekr. PN 7-1, Hardenbergstr. 36, D-10623 Berlin            IRC: kuroi

---

From: a sun <[email-masked]>
Date: Wed, 21 Jan 1998 14:19:54 -0800 (PST)

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