On Tue, Sep 27, 2011 at 03:48:29PM +0700, Robert Elz wrote: > | But it is better long term to move forward and allow for longer > | names. > > Why?
I was recently talking to some people who'd been working with some (physicists, I think) doing data-intensive simulation of some kind, and that reminded me: for various reasons, many people who are doing serious data collection or simulation tend to encode vast amounts of metadata in the names of their data files. Arguably this is a bad way of doing things, but there are reasons for it and not so many clear alternatives... anyway, 256 character filenames often aren't enough in that context. (This sort of usage also often involves things like 50,000 files in one directory, so the columnizing behavior of ls is far from the top of the list of relevant issues.) If we do end up going through and doing a full set of compat functions again, I think we should raise the limit to 1024... and maybe bump PATH_MAX to say 4096 too. > The 255 limit was just because that's how many bytes a one byte length > field permitted, not because anyone thought names that long made sense. > But if you're going to increase it, why stop at 511? That number > means nothing - the next logical limit would be 65535 wouldn't it? Well... yes but there are other considerations. As you noted, going past one physical sector is problematic; going past one filesystem block very problematic. Plus, as long as MMU pages remain 4K, allocating contiguous kernel virtual space for path buffers (since if NAME_MAX were raised to 64K, PATH_MAX would have to be at least that large) could start to be a problem. -- David A. Holland dholl...@netbsd.org