[Bug 184340] PATH_MAX not interoperable with Linux
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340 --- Comment #7 from Ben RUBSON --- On-going discussion & dev : https://lists.freebsd.org/pipermail/freebsd-current/2017-September/066908.html -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 184340] PATH_MAX not interoperable with Linux
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340 dcund...@a2hosting.com changed: What|Removed |Added Severity|Affects Only Me |Affects Some People -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 184340] PATH_MAX not interoperable with Linux
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340 dcund...@a2hosting.com changed: What|Removed |Added Version|9.2-RELEASE |CURRENT -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 184340] PATH_MAX not interoperable with Linux
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340
--- Comment #6 from Niall Douglas ---
(In reply to Jilles Tjoelker from comment #5)
I appreciate the detail in your reply. However, this is not a code development
problem - as you mention, openat() is the correct solution to programming long
paths. Rather it's a user problem - we are stuck with software written by
others which was designed around a Linux PATH_MAX of 4096. Being that we cannot
rewrite all this software to not be so stupid, it generates substantial gotchas
for end users.
In terms of how to refactor the BSD kernel to handle this, I believe NT simply
uses dynamic memory allocation for all paths, and therefore the 64Kb path limit
is tractable except when frequently modifying paths as the win32 layer likes to
do. An ideal solution for BSD would be some sort of variant storage which could
be either 256 bytes of path or a dynamic memory allocation to a path. Perhaps a
zero length path could mean "pointer to a dynamically allocated path follows",
so something like:
union
{
char path[256];// for paths < 255
struct
{
char _zero; // lowest byte in memory is zero
char _magic;// magic marker byte to detect unioned path
unsigned short length; // length of path
char *path; // dynamically allocated pointer to path
};
};
Anyway, I'm no expert in the BSD kernel, but I would find it nice to not have
to install ZFS on Linux just so I can zfs snapshot the volume onto FreeBSD as
my sole method of working around the BSD PATH_MAX limit.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 184340] PATH_MAX not interoperable with Linux
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340 Jilles Tjoelker changed: What|Removed |Added CC||jil...@freebsd.org Status|In Progress |Open --- Comment #5 from Jilles Tjoelker --- The limit cannot be removed entirely without a severe rework because subsystems like ktrace and audit need a copy of the pathname that the user cannot modify concurrently. The kernel rather likes allocating PATH_MAX or MAXPATHLEN sized buffers in general. This is already wasteful with PATH_MAX=1024 and even more so with 4096. Ideally, the majority of short pathnames would not waste so much memory. For a local change I would change the one in sys/sys/syslimits.h. Then recompile everything including packages. There are a few nasty APIs like realpath() that implicitly depend on PATH_MAX. Applications that insist on it can use longer pathnames by passing only short segments to system calls and using openat(2) and other *at functions. For example, find and rm from the base system do this (provided symlinks are not being followed, the current directory can be opened for reading and the pathnames passed to the utility themselves are not too long). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 184340] PATH_MAX not interoperable with Linux
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340
--- Comment #4 from Ben RUBSON ---
Hello,
I'm also facing this issue where PATH_MAX is too small (FreeBSD 10.3).
Is there any plan to :
- increase this value to a higher value ?
- make this value user-tunable ?
- remove this limitation ?
As a workaround, where can we change it by ourselves ?
find /usr/src/ -type f -exec grep -i "define.*path.*1024" {} \; -ls
There are a lot of defines which are related to paths and hard-coded to 1024,
so could be quite tricky to make this change without side-effects.
Thank you very much !
Ben
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 184340] PATH_MAX not interoperable with Linux
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340 Niall Douglas changed: What|Removed |Added CC||s_bugzi...@nedprod.com --- Comment #3 from Niall Douglas --- The excessively short PATH_MAX on FreeBSD is causing problems with stacking encryption layers like encfs on top of FreeBSD filing systems. Please see: https://lists.freebsd.org/pipermail/freebsd-fs/2016-May/023250.html Can we get motion on getting this limit raised please? Even 4096 bytes would make a big improvement. Niall -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
