Re: old bug: mount_nfs path/name is limited to 88 chars

On Tue, Jan 20, 2015 at 12:45:32PM +0100, Willem Jan Withagen wrote:
| On 2015-01-20 2:05, Xin Li wrote:
| >>Doing it in 11 makes sense since there is a compat layer for 10
| >>now? if I knew all of the steps I would happily do them as annoys
| >>me from time to time as well with the path length issue.
| >
| >Compat layer may break applications in other funny ways and we
| >probably have to return e.g. ENAMETOOLONG for legacy applications if
| >the names are too long to fit into the buffer, but I don't see any
| >easy solution either: I wish we have bumped it in 2003 when the struct
| >receives its first big revamp by bumping all statistic fields to 64-bit.
| 
| On 2015-01-20 1:23, Allan Jude wrote:> On 2015-01-19 16:20, Garrett >
| > Especially with ZFS, I find I have a lot more mounts now, under longer
| > and longer path names, and then I have
| > .zfs/snapshots/snapshotnamehere/path/to/file
| >
| > etc.
| >
| > Definitely a +1 for "this is something we need for 11"
| 
| +1
| 
| Well to be honest: Things are already broken for me ATM.
| I do have paths that are too long, and tools trip over it.
| 
| Things like building the locate database just don't have everything.
| Which is a pain, especially for finding things fast in backups of ZFS, 
| where the path is even more convoluted that what Allan suggests
| 
| So whether being bitten by the cat of the dog: it still hurts.
| 
| Perhaps it is an intermediate solution to add new settings which are 
| going to be used for userspace programs, like USER_MNAMELEN and 
| USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves 
| systemcalls. But then a lot of the other tool stuff would just function.

I have a patch at:
	http://www.ambrisko.com/doug/mount/latest.patch
for -current (Nov).  It should work with most file systems, that is I
tried to cover them all.  I haven't tested with ZFS but it should work.
I left some debug "HELLO's" in there just to make sure mounting looked
right.  They can be safely deleted.  If someone wants to test it and
report issues (with a simple test case) I can fix it and add it to
my test script.

This code won't be going into FreeBSD now since the 64 bit inode will
negate the need for it since the size will be a lot larger.

Thanks,

Doug A.