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 headers. 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 Arbitration. -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote@xxxxxxxxxxxxxxxx -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
