Windows long path experimenting report

Bill Sommerfeld sommerfeld at sun.com
Fri Jun 20 11:42:40 CDT 2008


On Fri, 2008-06-20 at 15:59 +0100, Paul Moore wrote:
> From this discussion, I get the impression that people aren't
> considering limits on platforms other than Windows. Is that right? Is
> it the case that on modern Unix, and MAC OS, MAX_PATH is essentially
> infinite? My recollection is that MAX_PATH was quite small in the
> early days of Unix. (Not that it makes much difference, I'm just
> curious).

I haven't followed this thread very closely, but I can answer that.

unix maintains a process's current working directory in the kernel as a
pointer to a filesystem object.  Some other operating systems maintain
it as a character string which is prepended to a non-absolute pathname.

The limits on unix constrains the length of a pathname string which can
be passed through the system call interface and a (smaller) limit on the
length of a pathname component/directory entry name.  There is no
enforced constraint on the total length of the absolute path names of
files which can be created deep in a filesystem; such constraints are
really hard to enforce if you can rename a directory.

Generally, a loop like:

while :
do
	mkdir aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
	cd    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
done

will run until the disk fills. 

Past a certain point it no longer becomes possible to name objects with
an absolute pathname, but it is still possible to name them with a
relative pathname starting near the object.  

Some versions of "rm -r" concatenate strings to form pathnames and are
stymied by such trees.  Others (including the version of solaris I'm
running on my laptop) use more flexible interfaces like fchdir or openat
and avoid the need to form long pathnames.

						- Bill



More information about the Mercurial-devel mailing list