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

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.

--WjW