From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue, 14 Apr 1998 10:05:08 -0500
From: G. David Butler gdb@dbSystems.com
Subject: [9fans] allowing long file names with a space too
Topicbox-Message-UUID: 757ff986-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19980414150508.HLihI7RavBt-b-a7es41tiywoorE7CDMo5yUQ9Ukp5g@z>

From: Elliott.Hughes@genedata.com

>So why bother with an upper limit on length at all? Why trade one
>hard-coded assumption for another? Because you're implementing
>some specific protocol?

Good point.  Because of stat/wstat the limit is MAXFDATA(8192)-88=8104
unless you include the 88 octets as part of the header.

The biggest problem with ~8k file names is practical limits of
implementations.  For example, after staring a while at calculations
of the wasted disk space that results from allocating name[256] when
most names will fit in 64 (21 unicode characters), I thought a limit
of 64 would be OK :-<.  256-64 = 192 * 6 million files = 1.1 Gigabyte,
and if only 10 are used most of the time then it is 1.5 GB wasted.

Wow.

In defense, I came up with a design for variable length file names
in the file server that limit the largest name to BUFSIZE, or 4088
octets with RBUFSIZE set to 4096.  My system doesn't expect many files
over 1k so my RBUFSIZE is 1024 (yes, I added triple indirects) and
the file name limit is 1016.

Now that 9P can support file names up to 8104 octets (including the
NULL), and the fileserver will support names that depend on tuning,
what is the best way for a server to interact with 9P?

I think a Tcreate/Twstat that has a name too long for the server
should return Enamelen "create/wstat -- file name too long".

David Butler
gdb@dbSystems.com