old bug: mount_nfs path/name is limited to 88 chars
Willem Jan Withagen
wjw at digiware.nl
Tue Jan 20 11:46:11 UTC 2015
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
More information about the freebsd-current
mailing list