--lMM8JwqTlfDpEaS6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 19, 2001 at 11:04:38PM -0500, Kadari Mayson wrote:
> No, I know what you're saying.  But we live in a service oriented
> industrial/capitalistic society, nothing is ever completely free.  Somewh=
ere
> along the line, you are going to have to pay for something.

Right, and I'm saying that having to maintain the (easily accessible,
easily reparable by someone with half a code clue) Netatalk on the
(single) server is operationally cheaper than having to maintain the
(commercial, pay-to-upgrade) software on (many) the client macs.

Your previous suggestion, btw, that there is SMB-speaking software
"free to students" doesn't hold up so well with this argument.

> but it does not integrate well into later environments due to
> speed issues and certain other limitations like the 32 character
> thing.

What speed issues? Do you have some benchmarks?

What "other limitations"? Could you list some?

The 32 character limit is a non-issue if all you're exporting is
disk space for macs to use. It only becomes problematic if you have
multiple OSes (some of which can have filenames longer than 32
characters) trying to store files in the same space.

> Never mind that you are using Netatalk on NetBSD's ffs which is
> a "flat" filesystem which completely obliterates Classic and Carbon
> PEF applications' resource forks (but this is also a ffs limitation),
> you can only store data files, no applications that are not Mac OS
> X Cocoa or Carbon Mach-O "bundles" will even be able to housed on
> that volume.

What are you talking about? Netatalk uses AppleDouble to preserve
Mac OS resource forks, and running applications from a Netatalk-exported=20
partition works just fine. (I should know, I run NiftyTelnet-ssh
from one daily.)

> I think the whole point of the discussion was about
> "how do I fix Netatalk so it can export filenames that are greater than 32
> characters" and the answer is: "you can't".  If you are only storing data
> files for backup purposes, in a very small environment, then it's ok.  But
> if you're trying to do anything more demanding then Netatalk is not your
> answer.

And my response to that question was "You can't, but here's a hack
that'll make administration of the system easier." What's your
problem with that, precisely? Why was any of this leave for you to
badmouth Netatalk wholesale?

> > I don't think I've ever actually suggested that Netatalk should
> > magically make the filename-length problem go away. I've been
> > suggesting all along just that it make it easier for the
> > administrator to deal with. I think plenty of people would find
> > Netatalk totally sufficient for their needs, and this small addition
> > would make them much happier.
> But it's not a "small addition".  How old is Netatalk?  6-7 years old?  If
> it was that easy, it would certainly have been added by now.

Would you please re-read my suggestion and explain to me how it is
non-trivial?

It is a thirty minute hack to add syslog()ing when Mac OS clients
encounter a directory containing files which they will be unable
to see. It's another five minutes to add a command line flag to
control whether or not that logging happens.

I would do this except that, for my needs, there's nothing wrong
with Netatalk (and neither do I control the box on which I use a
Netatalk partition, nor does it run NetBSD), so it's not my itch to
scratch.

I think the only reason something like this wasn't done is that these
nebulous Netatalk developers thought that it would be better to
solve the problem correctly than with a kludge. But sometimes
(especially with non-trivial problems like mapping a >32 char
filename healthily into a file system with a 32 char cap), a kludge
is better than nothing in the mean time.

> Well, I was trying to find the exact reference(s), but I couldn't find th=
em
> (didn't search very long anyway).  But the Netatalk developers have said
> many many times in the past that it's not that easy to implement long
> filename support, and they also hinted that it might be in Netatalk 3.0, =
but
> it's a /long/ way off (I found that in the mailing list just now).

Whatever. It's clearly impossible to make, say, MacOS 8.6 see
filenames longer than 32 chars. The important part is figuring out
how to make it easy for users of Netatalk to work around the
problem.

> That's why I use my Q800 as a file/web server.  I paid $4500 for it in 19=
93,
> and I'm going to use it every day until it melts.  I am trying to maximize
> the performance, and for my money, Netatalk just doesn't cut it even if I
> were using only OS 9, which I'm not.  I have PCs on my home network (even
> though my Mac OS X boxes are my primary work stations) and it's silly to
> have both Netatalk and Samba running doing the same exact thing but with =
two
> separate protocols.

That's swell. But your situation is not everyone's situation, and
it's unfair and presumptive to suggest that people with all-Mac OS
networks would find your way to be the right way.

--=20
       ~ g r @ eclipsed.net

--lMM8JwqTlfDpEaS6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjv6LzQACgkQ9ehacAz5CRpk5ACfRRW5AmnMXmoMPivTzNg3V+6G
sQIAoK7m8119/gQ+kvHEq1saG7QN14/2
=eUWo
-----END PGP SIGNATURE-----

--lMM8JwqTlfDpEaS6--