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

On Tue, Nov 20, 2001 at 12:48:49PM -0600, Donald Lee wrote:
> Given that the MacOS on the client side only knows about 31 character
> filenames, (not 32) how would you approach this problem?

Well, actually, filenames can be 32 characters, but the 32nd
character is special. It designates whether or not the file is
"visible" in the finder. The finder (and the Mac GUI toolkit save
dialog) won't let you name a file something longer than 31 chars,
and the easiest way to flip this last character byte is using
ResEdit, but, last I heard, that's where the information about
visibility lives.

Huh. That makes me wonder if these >32 character files are actually
visibile to the finder, and then hidden by it, but could be seen on
the Mac OS side using a tool like ResEdit. Might be an interesting
experiment for the curious.

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

> I'm not so certain that silently failing is such a horrible thing,
> given that the idea of netatalk is that the files are created and
> consumed on the Macintosh.  Hence, these >31 names can't be
> created in the first place.

Ah, but that's NOT the idea always. Plenty of folks point Netatalk,
Samba, and NFS all at the same directory tree so that users in a
multi-OS office/school (and it's far more frequently a school, in my
experience) can share the same server space and get to their files
(like, say, MS Word files) from any platform. In mixed OS
installations like this, Netatalk really needs have a way to be
more graceful.

--=20
       ~ g r @ eclipsed.net

--dxRQSzdsN/lOP445
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

iEYEARECAAYFAjv63RsACgkQ9ehacAz5CRrnZACeKdrHB/CVRUZhrUHuaEz3l2uc
3cIAnRRf3/YqeHAgU0XIaGp+jIVuQ/m3
=DDmh
-----END PGP SIGNATURE-----

--dxRQSzdsN/lOP445--