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

On Tue, Nov 20, 2001 at 10:01:49PM -0600, Donald Lee wrote:
> I'm not clear on the concept of "change directory" with a GUI-based
> system.  Mac users don't know about "cd" or "ls".  They just look
> at their windows on the screen.

Uh, sure, but the Netatalk server must execute a chdir(2) (or
readdir(3), whatever) within the exported FFS (or LFS, or whatever)
in order to hand the directory listing to a client who just
double-clicked a folder. That's where it's easy to add code to the
server, and the only place this matters. The client's behavior is
totally irrelevant.

> I'm also not clear on how the finder deals with the contents of
> directories.  Depending on how it does its scans, how frequently
> these files are encountered, and  what and how much gets cached on
> the client side, this approach might provide too little or way too
> much output in syslog.  Too much tends to make it useless, because
> the signal gets lost in the noise.

Well, if the Finder tells the AppleTalk server to fstat(2) every damn
thing in a partition when it mounts the partition (which I'm pretty
sure it doesn't based on the behavior and response on the client end
and the insane memory usage that'd lead to in a large partition),
so much the better; all the syslog messages end up together and
it's easier for the administrator to fix the too-long names.

Let me remind you that I'm suggesting this be an *optional* flag for
the Netatalk daemon. Those who don't want to hear it don't need to.

> Logging is also not helpful to the client.  The client still gets
> a deafening silence.

Right, but fixing that problem is significantly more complicated. If
you've got (or are) an administrator who cares, it would at least
allow him (or you) an easy way to notice this problem on the fly
without having to do his (or your) own find(1) on a nightly basis.

I'm not saying this fixes the problem, just that it makes it easier
to diagnose. (At least someone's hearing something if he wants to
listen.)

> I'm not saying it can't be done, but it strikes me as non-trivial.

And I'd posit that fixing the client end *is* impossible without
resorting to MS-DOS style BS. You can't just magically map a string
greater than 31 chars into a 31-char space and be sure that you've
done away with all collisions any other way. (It doesn't have to
look quite as ugly, but the principle has to be the same.) And
writing code to do that sounds like a distinctly un-fun proposition.
(And let's not even get to the fact that Mac OS makes only a visual
distinction between case in filenames. Foo, fOo, and foO will
collide for the Finder.)

> I'd be more inclined to come up with a hash-function that provided
> a somehow illegal, but unique name, and make access to the hashed, too-lo=
ng
> file give an error.  Logging could still be done, but could be pretty
> spare.  This would give the user some indication that something
> was wrong.

Well, that presumes that there's some error type defined for this on
the Mac OS side. Do you know that? I sure don't. And if I open a
folder which I know has about fifty files I'm not going to see,
but I'm okay with that right now because I can see the ones I want,
I don't want to click OK fifty times.=20

There're the principles of least surprise and utility here. There
isn't a damn thing the client can do about not being able to see
the file (except move to an OS with a sane filename limit, which
may or may not be possible, and will probably happen when he notices
he can't see files in one place he can in another if it is possible),
so why hassle him with it?

> It would also make netatalk admins hate me. ;->

Not if they didn't run Netatalk with the flag set. They'd continue
to be blissfully ignorant. ;^>

I'd again suggest that people who really want to see this changed,
in whatever way, take it to whoever's maintaining whatever Netatalk
they're using. I'd also suggest that an (easy) scheme like mine that
doesn't really do the right thing but helps a bit will be more
likely to be accepted than a (hard) scheme that fixes everything...
unless you just do all the code and submit it, I suppose. As I've
said several times, I'd be glad to do all that myself if Netatalk
impacted my life at all. But it doesn't.

I know some of you involved in this discussion who sound like you
use Netatalk know how to code...

--=20
       ~ g r @ eclipsed.net

--RyOXVFQXzAE23HDB
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

iEYEARECAAYFAjv7LvUACgkQ9ehacAz5CRpTtwCgjjf7JoOWAvLLfekhkU7h2ggC
LLMAn28UOpoXkWgzWi4MQ83HvyCn+0m4
=dj4D
-----END PGP SIGNATURE-----

--RyOXVFQXzAE23HDB--