gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]

Don Quixote de la Mancha quixote at
Sat Nov 5 11:19:41 UTC 2011

The find command will easily determine the longest path in your directory tree.

If "~/foo" is the root of the tree that you want to burn, try:

   $ cd ~/foo
   $ find . -print > ../paths.txt

I expect there is some simple combination of command-line tools that
would yield the length of the longest line in paths.txt, but I don't
know what they would be.

 Instead I suggest opening it in your favorite text editor, then
scrolling from the top to the bottom of the file.  Whenever you see
that a line has wrapped, make your window wider.  You will likely have
to move the left edge of the window offscreen.

Once you get to the bottom of the file, scroll back up to find the
line that just touches the right edge of the window.  Copy that line
to the Clipboard, then paste it into a new file.

The wc command - for "word count" - will tell you how many characters
are in that new file.  Suppose it is called "longest.txt":

   $ wc longest.txt

I was mistaken when I said that the UNIX maximum path length was given
by the MAXPATH #include file macro.  It's actually PATH_MAX.

The chances are pretty good that PATH_MAX is defined by a C Standard
Library header on Windows.  While PATH_MAX is a UNIX operating system
concept, the Windows C Standard Library more or less attempts to be
source-compatible with the simpler kinds of UNIX source code.

If PATH_MAX for Windows doesn't turn up in a Google search and you
don't have Visual Studio, there is a free-as-in-beer version of Visual
Studio, but that would be a lot of stuff to install just to look up
one line in a header file.  Instead look for PATH_MAX in the MinGW

MinGW is a port of the GNU toolchain that produces Win32 binaries that
is Free as in Freedom.  If PATH_MAX is defined for Windows some MinGW
header would have it.  Quite likely you could find that header where
you could get at it with a web browser without having to actually
install anything.

In general, UNIX allows directories to be nested to arbitrary depths.
It's just that the total length of an absolute pathname is limited.
If your file and directory names are shorter, your directories can be
nested more deeply.

A while back I discovered a bug in Mac OS X which was quite similar to
this, but rather than file paths, OS X has something called a "device
path".  The device drivers in the OS X kernel are connected in a tree
structure, just like a filesystem heirarchy.  At the root of the tree
is the motherboard driver, at the tip of a branch for a storage device
is the name of a filesystem.

The company I was working for developed a storage driver for a client.
 On PowerPC Macs, our driver worked great.  The identical driver
source when compiled for Intel would not work at all on Mac Pros, the
high-end desktop Macs.  It did work on less-powerful Intel Macs such
as my MacBook Pro.

A great deal of debugging as well as poring through much of what is
fortunately open source determined that OS X' Disk Arbitration daemon
- the OS X equivalent of the UNIX automounter - was asking the kernel
for the device path for the volume it wanted to mount.

On Mac Pros, but JUST Mac Pros, the hardware was so much more complex
and there were so many more devices in the tree that the resulting
path would not fit in the fixed-size buffer that the system call
allowed.  I think that was 512 bytes.  There was absolutely no way
that length could be increased without breaking binary compatibility
with existing programs.

I reported the bug to Apple.  They fixed it in the next build of the
system somehow, but without increasing the size of the buffer that
system call could take.

I never looked into it, but I expect they worked around it by asking
for the path one component at a time.  That would make Disk
Arbitration work just fine, but any other userspace program that
depended on retrieving the device path would still break on Mac Pros,
and would have to use the same workaround that Apple used for DIsk

Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
quixote at

More information about the users mailing list