Continuing the OT discussion...

>> What **should** Netatalk do.  Even logging - what should it log, and in
>> which cases?  Would you want it to log the name of every file that
>> has been in some way referenced, but has a name > 31 chars?
>> If a file request comes in to netatalk for a 31 char file, does it
>> log any potential ambiguity?  Does it refuse service if there is
>> ambiguity?  What error?
>
>When a client changes directory, I want Netatalk (optionally, based
>on a command line flag) to scan that directory (find(1) can do this
>dead simply) for files with names longer than 31 characters and
>syslog(3) the fact that they're not being displayed to the client
>(including the full directory path and filename on the Unix side).
>Really. This is simple. I promise.

Sure, the implementation on the server is pretty easy.  My question
is with the semantics.

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

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

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

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-long
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.

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

-dgl-