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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
