[1.35.0] Filename lengths, path lengths, leading numerics, multiple periods?

In trying to do merges into the release branch, I'm running into precommit check failures due to filename and path issues. I've run the inspection report for name issues. See http://mysite.verizon.net/beman/inspect-names.html The inspect program is treating as errors: * Filenames longer than 31 characters. * Filenames beginning with a non-alphabetic character. * Directory depth greater than 8. * Path length greater than 100 characters. * More than one period ('.') in a name. These requirements were put in place to ensure that Boost on a CD would be readable on systems that only supported the minimum ISO 9660:1988 standard. Since then, ISO 9660:1999 has come out, removing many of the old restrictions. See http://www.y-adagio.com/public/standards/iso_cdromr/tocont.htm The only remaining ISO 9660:1999 restriction that affects Boost is a maximum path length of 207. To calculate that, we assume a root in the form boost_X_XX_X. I burned the current trunk onto a CD, and verified that the very deep and long paths could be read without problems on Windows (XP SP2), Linux (Ubuntu 7.10), and Mac OS X (Leopard). I recommend we remove all restrictions except for a path length limit of 207 characters. --Beman

Beman Dawes wrote:
In trying to do merges into the release branch, I'm running into precommit check failures due to filename and path issues.
I've run the inspection report for name issues.
See http://mysite.verizon.net/beman/inspect-names.html
The inspect program is treating as errors:
* Filenames longer than 31 characters.
I believe this is still a restriction for Mac OS filenames?
* Filenames beginning with a non-alphabetic character.
* Directory depth greater than 8.
Very hard to avoid with DocBook generated documentation?
* Path length greater than 100 characters.
Very hard to avoid with DocBook generated documentation?
* More than one period ('.') in a name.
Should be work-roundable.
These requirements were put in place to ensure that Boost on a CD would be readable on systems that only supported the minimum ISO 9660:1988 standard.
Since then, ISO 9660:1999 has come out, removing many of the old restrictions. See http://www.y-adagio.com/public/standards/iso_cdromr/tocont.htm
The only remaining ISO 9660:1999 restriction that affects Boost is a maximum path length of 207. To calculate that, we assume a root in the form boost_X_XX_X.
I burned the current trunk onto a CD, and verified that the very deep and long paths could be read without problems on Windows (XP SP2), Linux (Ubuntu 7.10), and Mac OS X (Leopard).
Whew :-)
I recommend we remove all restrictions except for a path length limit of 207 characters.
I suspect the 31-character limit may still be valid, but perhaps someone can disabuse me of that? John. PS Where are we with the release process? Do we have some kind of schedule / deadlines for being ready to ship: I'm a little concerned about some of the regex library tests which haven't changed in ages, but are none the less failing due to exceptions thrown from Boost.Thread and Boost.Test. I'm not sure that this is necessarily these libraries fault, but we really ought to try and get to the cause of this...

On Nov 23, 2007 10:16 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Beman Dawes wrote:
The inspect program is treating as errors:
* Filenames longer than 31 characters.
I believe this is still a restriction for Mac OS filenames?
Mac OS X at least doesn't impose the 31 character limit any more. In older versions of Mac OS, the file system supported longer filenames but Finder didn't :-( Stjepan

Stjepan Rajko wrote:
On Nov 23, 2007 10:16 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Beman Dawes wrote:
The inspect program is treating as errors:
* Filenames longer than 31 characters. I believe this is still a restriction for Mac OS filenames?
Mac OS X at least doesn't impose the 31 character limit any more. In older versions of Mac OS, the file system supported longer filenames but Finder didn't :-(
I think this is pretty much explained at: http://en.wikipedia.org/wiki/Hierarchical_File_System http://en.wikipedia.org/wiki/HFS_Plus Seems that since HFS+ has been available for almost 10 years we could drop the 31 char filename limit. Operation of Finder on old systems doesn't seem like a big priority. Jeff

Beman Dawes wrote:
...
The only remaining ISO 9660:1999 restriction that affects Boost is a maximum path length of 207. To calculate that, we assume a root in the form boost_X_XX_X.
Based on the positive feedback (and no negative feedback) so far, I've replace the separate name and path size checks with a single maximum path size of 207. Since this was a long weekend for lots of folks in the US and Canada, I realize a killer argument against the change could surface in a few days. But I need to clear stuff off my do list this weekend, since I'll be traveling next week. We can always revert. --Beman
participants (4)
-
Beman Dawes
-
Jeff Garland
-
John Maddock
-
Stjepan Rajko