5 ms·
That seems like a bad idea because people will then use inconsistent max path lengths.
by the_mitsuhiko 10y ago
That seems like a bad idea because people will then use inconsistent max path lengths.
- jerf 10y agoWhat is the correct consistent max path length?
- jstimpfle 10y agoIt simplifies implementations. For example, typically you need to be able to store paths in a consecutive area of memory or storage. Knowing that paths don't exceed a certain size means you can know that a particular allocation strategy (like static allocation, for a simple example) will be sufficient.
- klodolph 10y agoMostly it's for stuff like readlink(), which returns a path in a user-supplied buffer. How big should the buffer be? The Linux man page actually suggests doing lstat() to size the buffer, with a note that this is susceptible to a race condition!
- jerf 10y agoI don't question that using wrong values can simplify implementations. But if we're going to complain about people using inconsistent lengths, what's the consistent one they should be using? If you can't name one than the inconsistency criticism is null. As long as I'm already typing, the real problem here is that path lengths do not in fact fit into any practical statically-sized buffer. While statically-sized buffers have their utility and aren't going anywhere, they're an optimization, or a special case, in a world that is fundamentally dynamically-sized. In the 1970s it made sense for hardware reasons to treat "static buffer" as the default case and make dynamically-sized buffers the harder case, but that's not correct today on any level, code correctness, developer convenience, API cleanliness, ease of use, anything. Yes, I understand that this is a kernel API and I am aware I'm making a deep structural criticism of UNIX kernels here, and that fixing it would be a significant challenge. It would take quite a bit of fundamental rethinking of how things work to do something like pass the kernel a function pointer to allocate a given bit of user-space RAM or something, or pass it a static buffer with a function to call on overflow, or something, and I am not claiming this would be easy. (Note the distinction between "dynamically sized" and "arbitrarily large"; a 3GB path is 99.9999+% either some sort of bug or an attack, so having a total max path length has advantages too. But you can do something like make it 1MB, something very generous, without making everything that uses paths allocate 1MB per path.)
- jstimpfle 10y agoI can understand your side, but on the other hand... I'm sure there are a lot of (sub)systems even today that just can't have objects larger than 4096 bytes. Also has 4096 bytes ever been restricting to you? I once heard from someone doing evil things and hitting NAME_MAX, but there is no problem just treating that rare case as some sort of I/O error. Everything IO can always fail anyway.
- loeg 10y agoThe idea is you need to allocate and resize larger if your initial buffer was too small. It doesn't matter what inconsistent length you start with as long as you scale it up as needed.
- the_mitsuhiko 10y agoThat's a DOS in the kernel waiting to happen.
- loeg 10y agoUserspace is responsible for constructing paths. Also, Hurd has some interesting views on what belongs in the kernel (and anything to do with paths probably doesn't). (I don't use or hack on Hurd, it's just an interesting example for PATH_MAX.)
- the_mitsuhiko 10y agoI will still need to pass thebpath to the kernel. If I ipen a 3GB filename'd file the kernel will have an issue.
- loeg 10y agoWhy do you think it would be a problem?
- ygra 10y agoI actually like that some Windows APIs you pass a buffer to will tell you if the buffer was too small and the necessary size to accommodate the result, requiring a bit less guessing.
- dom0 10y agoIt's still a race though - you have to loop (possibly indefinitely).