[guideline] 31 character filenames?
Our current guidelines[1] say filenames should not exceed 31 characters. This was recently brought to my attention by a bug[2] from someone who actually cares because he uses the ODS-2 filesystem on OpenVMS. On a lark, I hacked the inspect tool to check for too-long filenames and lo! found a bazillion. Most (but not all) violations are from doc files auto-generated by doxygen and docbook, but which nevertheless go out with the boost distribution and so should conform. (Right?) So, should we care? Considering that we have little control(?) over how doxygen and docbook generate their files? I have fixed the bug in question, but it feels like a token effort. Should we just drop support for niche filesystems like ODS-2, and close all future bugs "won't fix"? [1] http://www.boost.org/development/requirements.html [2] https://svn.boost.org/trac/boost/ticket/6196 -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 27 March 2012 22:08, Eric Niebler <eric@boostpro.com> wrote:
Our current guidelines[1] say filenames should not exceed 31 characters. This was recently brought to my attention by a bug[2] from someone who actually cares because he uses the ODS-2 filesystem on OpenVMS. On a lark, I hacked the inspect tool to check for too-long filenames and lo! found a bazillion. Most (but not all) violations are from doc files auto-generated by doxygen and docbook, but which nevertheless go out with the boost distribution and so should conform. (Right?)
So, should we care? Considering that we have little control(?) over how doxygen and docbook generate their files? I have fixed the bug in question, but it feels like a token effort. Should we just drop support for niche filesystems like ODS-2, and close all future bugs "won't fix"?
It is different for source and documentation files, because documentation files aren't going to break a build.
On 3/27/2012 2:22 PM, Daniel James wrote:
On 27 March 2012 22:08, Eric Niebler <eric@boostpro.com> wrote:
Our current guidelines[1] say filenames should not exceed 31 characters. This was recently brought to my attention by a bug[2] from someone who actually cares because he uses the ODS-2 filesystem on OpenVMS. On a lark, I hacked the inspect tool to check for too-long filenames and lo! found a bazillion. Most (but not all) violations are from doc files auto-generated by doxygen and docbook, but which nevertheless go out with the boost distribution and so should conform. (Right?)
So, should we care? Considering that we have little control(?) over how doxygen and docbook generate their files? I have fixed the bug in question, but it feels like a token effort. Should we just drop support for niche filesystems like ODS-2, and close all future bugs "won't fix"?
It is different for source and documentation files, because documentation files aren't going to break a build.
OK, is that the intent of the guideline? What happens when someone tries to unpack the boost tarfile on a filesystem that doesn't support long filenames? Are the doc files with long names silently dropped? Or is it an error? Or...? :-/ -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 27 March 2012 23:25, Eric Niebler <eric@boostpro.com> wrote:
On 3/27/2012 2:22 PM, Daniel James wrote:
On 27 March 2012 22:08, Eric Niebler <eric@boostpro.com> wrote:
Our current guidelines[1] say filenames should not exceed 31 characters. This was recently brought to my attention by a bug[2] from someone who actually cares because he uses the ODS-2 filesystem on OpenVMS. On a lark, I hacked the inspect tool to check for too-long filenames and lo! found a bazillion. Most (but not all) violations are from doc files auto-generated by doxygen and docbook, but which nevertheless go out with the boost distribution and so should conform. (Right?)
So, should we care? Considering that we have little control(?) over how doxygen and docbook generate their files? I have fixed the bug in question, but it feels like a token effort. Should we just drop support for niche filesystems like ODS-2, and close all future bugs "won't fix"?
It is different for source and documentation files, because documentation files aren't going to break a build.
OK, is that the intent of the guideline? What happens when someone tries to unpack the boost tarfile on a filesystem that doesn't support long filenames? Are the doc files with long names silently dropped? Or is it an error? Or...? :-/
I can't comment on the guideline since it was written before I was involved with Boost. I don't have access to any platforms where this is an issue, but no one has ever reported any problems with the documentation. I think that's a pretty strong indicator that it isn't a major problem. While someone might need to build on such a platform, they can probably view the documentation elsewhere, or from the web. There's a bug in the code for truncating boostbook reference documentation which causes the filenames to be a bit longer than it should be (quite telling that no one noticed in the years since I implemented it). I'm fixing that now, although I'm not sure how comprehensive it is, it certainly won't truncate ids given by the user. Doxygen users might want to look at the script 'gil' uses to reduce the file length for its doxygen documentation.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Tuesday, March 27, 2012 11:59 PM To: boost@lists.boost.org Subject: Re: [boost] [guideline] 31 character filenames?
On 27 March 2012 23:25, Eric Niebler <eric@boostpro.com> wrote:
On 3/27/2012 2:22 PM, Daniel James wrote:
On 27 March 2012 22:08, Eric Niebler <eric@boostpro.com> wrote:
Our current guidelines[1] say filenames should not exceed 31 characters. This was recently brought to my attention by a bug[2] from someone who actually cares because he uses the ODS-2 filesystem on OpenVMS. On a lark, I hacked the inspect tool to check for too-long filenames and lo! found a bazillion. Most (but not all) violations are from doc files auto-generated by doxygen and docbook, but which nevertheless go out with the boost distribution and so should conform. (Right?)
So, should we care? Considering that we have little control(?) over how doxygen and docbook generate their files? I have fixed the bug in question, but it feels like a token effort. Should we just drop support for niche filesystems like ODS-2, and close all future bugs "won't fix"?
It is different for source and documentation files, because documentation files aren't going to break a build.
OK, is that the intent of the guideline? What happens when someone tries to unpack the boost tarfile on a filesystem that doesn't support long filenames? Are the doc files with long names silently dropped? Or is it an error? Or...? :-/
I can't comment on the guideline since it was written before I was involved with Boost. I don't have access to any platforms where this is an issue, but no one has ever reported any problems with the documentation. I think that's a pretty strong indicator that it isn't a major problem. While someone might need to build on such a platform, they can probably view the documentation elsewhere, or from the web.
There's a bug in the code for truncating boostbook reference documentation which causes the filenames to be a bit longer than it should be (quite telling that no one noticed in the years since I implemented it). I'm fixing that now, although I'm not sure how comprehensive it is, it certainly won't truncate ids given by the user. Doxygen users might want to look at the script 'gil' uses to reduce the file length for its doxygen documentation.
As I recall, the 31 char limit was because we wanted to be able to copy all the files on a CD. I'm not sure this is still important (you'd probably zip anyway?), so I agree it should be dropped as a requirement, and the bugs 'won't-fixed'. I've had Doxygen generated filenames that were too long (for Windows?) and had to use the mechanism provided to make them shorter, so I think we need to keep that (preferably bug-free ;-) Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Wed, Mar 28, 2012 at 4:44 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
... As I recall, the 31 char limit was because we wanted to be able to copy all the files on a CD.
IIRC, there were still some users on old Macs with a 31 char limit on hard disk filenames.
I'm not sure this is still important (you'd probably zip anyway?), so I agree it should be dropped as a requirement, and the bugs 'won't-fixed'.
I've had Doxygen generated filenames that were too long (for Windows?) and had to use the mechanism provided to make them shorter, so I think we need to keep that (preferably bug-free ;-)
Windows maximum for a directory or file name depends on the particular file system, but is typically 255 characters. Looking at http://en.wikipedia.org/wiki/Comparison_of_file_systems, 255 seems a pretty typical limit for modern file systems. Windows maximum for a path is 32,767 Unicode characters in theory, but a path longer than 260 (I.E. MAX_PATH) requires special syntax so that's a practical limit for some uses. There is also the question of readability and usability. At some point, really long file names are an irritation, even if not technically illegal. So perhaps we might bump the limit at bit, but let's not get too extreme. --Beman
On Wed, Mar 28, 2012 at 10:50 AM, Beman Dawes <bdawes@acm.org> wrote:
On Wed, Mar 28, 2012 at 4:44 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
... As I recall, the 31 char limit was because we wanted to be able to copy all the files on a CD.
IIRC, there were still some users on old Macs with a 31 char limit on hard disk filenames.
I'm not sure this is still important (you'd probably zip anyway?), so I agree it should be dropped as a requirement, and the bugs 'won't-fixed'.
I've had Doxygen generated filenames that were too long (for Windows?) and had to use the mechanism provided to make them shorter, so I think we need to keep that (preferably bug-free ;-)
Windows maximum for a directory or file name depends on the particular file system, but is typically 255 characters. Looking at http://en.wikipedia.org/wiki/Comparison_of_file_systems, 255 seems a pretty typical limit for modern file systems.
Windows maximum for a path is 32,767 Unicode characters in theory, but a path longer than 260 (I.E. MAX_PATH) requires special syntax so that's a practical limit for some uses.
There is also the question of readability and usability. At some point, really long file names are an irritation, even if not technically illegal.
So perhaps we might bump the limit at bit, but let's not get too extreme.
Solaris tar can't unpack the tar available for download because of path size.
--Beman
Regards, -- Felipe Magno de Almeida
On Wed, Mar 28, 2012 at 9:52 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
Solaris tar can't unpack the tar available for download because of path size.
Interesting. Do you know if that is because of a Solaris limit on path size or because of a limit imposed by a particular file system? What file system are you using? Thanks, --Beman
On Wed, Mar 28, 2012 at 11:16 AM, Beman Dawes <bdawes@acm.org> wrote:
On Wed, Mar 28, 2012 at 9:52 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
Solaris tar can't unpack the tar available for download because of path size.
Interesting. Do you know if that is because of a Solaris limit on path size or because of a limit imposed by a particular file system? What file system are you using?
It is because tar from solaris doesn't handle a extension to the tar format that allows path names of unlimited size. I had to use gtar to uncompress. It did but it complained a lot of the gid_t number being (uint32_t)-1 and being out of its limits of [std::numeric_limits<int32_t>::min(), std::numeric_limits<int32_t>::max()] and returned a process return different of 0. Since it was a automated script I changed to using the zip file. It is not a limitation of the filesystem, since unzip works flawlessly.
Thanks,
--Beman
Regards, -- Felipe Magno de Almeida
On 28 March 2012 15:21, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On Wed, Mar 28, 2012 at 11:16 AM, Beman Dawes <bdawes@acm.org> wrote:
Interesting. Do you know if that is because of a Solaris limit on path size or because of a limit imposed by a particular file system? What file system are you using?
It is because tar from solaris doesn't handle a extension to the tar format that allows path names of unlimited size.
Looking at Wikipedia, it seems that the original tar file format has a maximum path length of 100 characters, so I guess that's what we're hitting?
On 28/03/2012 14:50, Beman Dawes wrote:
Windows maximum for a path is 32,767 Unicode characters in theory, but a path longer than 260 (I.E. MAX_PATH) requires special syntax so that's a practical limit for some uses.
FWIW "good" Windows applications should be able to read/use 32,767 character paths but only write 260 character paths. Unfortunate as it may be, a great many applications use the MAX_PATH macro has a hard upper limit so cannot read longer paths, additionally many of Windows built-in tools fail to handle long paths correctly - most significantly Explorer (making it difficult to deal with long paths correctly at all). Just thought it was worth saying. Iain
on Wed Mar 28 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
On Wed, Mar 28, 2012 at 4:44 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
... As I recall, the 31 char limit was because we wanted to be able to copy all the files on a CD.
IIRC, there were still some users on old Macs with a 31 char limit on hard disk filenames.
I'm not sure this is still important (you'd probably zip anyway?), so I agree it should be dropped as a requirement, and the bugs 'won't-fixed'.
I've had Doxygen generated filenames that were too long (for Windows?) and had to use the mechanism provided to make them shorter, so I think we need to keep that (preferably bug-free ;-)
Windows maximum for a directory or file name depends on the particular file system, but is typically 255 characters. Looking at http://en.wikipedia.org/wiki/Comparison_of_file_systems, 255 seems a pretty typical limit for modern file systems.
Windows maximum for a path is 32,767 Unicode characters in theory, but a path longer than 260 (I.E. MAX_PATH) requires special syntax so that's a practical limit for some uses.
There is also the question of readability and usability. At some point, really long file names are an irritation, even if not technically illegal.
So perhaps we might bump the limit at bit, but let's not get too extreme.
Wasn't this limit related to what could be encoded on an ISO CD/DVD or something? That's my recollection. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mar 27, 2012, at 5:08 PM, Eric Niebler wrote:
Our current guidelines[1] say filenames should not exceed 31 characters. This was recently brought to my attention by a bug[2] from someone who actually cares because he uses the ODS-2 filesystem on OpenVMS. On a lark, I hacked the inspect tool to check for too-long filenames and lo! found a bazillion. Most (but not all) violations are from doc files auto-generated by doxygen and docbook, but which nevertheless go out with the boost distribution and so should conform. (Right?)
So, should we care? Considering that we have little control(?) over how doxygen and docbook generate their files?
Doxygen has a SHORT_NAMES configuration option: "If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but less readable) filenames." I've never used it myself.
AMDG On 03/27/2012 02:08 PM, Eric Niebler wrote:
Our current guidelines[1] say filenames should not exceed 31 characters. This was recently brought to my attention by a bug[2] from someone who actually cares because he uses the ODS-2 filesystem on OpenVMS. On a lark, I hacked the inspect tool to check for too-long filenames and lo! found a bazillion. Most (but not all) violations are from doc files auto-generated by doxygen and docbook, but which nevertheless go out with the boost distribution and so should conform. (Right?)
So, should we care? Considering that we have little control(?) over how doxygen and docbook generate their files?
We should be able to adjust the file names generated by docbook.
I have fixed the bug in question, but it feels like a token effort. Should we just drop support for niche filesystems like ODS-2, and close all future bugs "won't fix"?
[1] http://www.boost.org/development/requirements.html [2] https://svn.boost.org/trac/boost/ticket/6196
In Christ, Steven Watanabe
Eric Niebler <eric <at> boostpro.com> writes:
Our current guidelines[1] say filenames should not exceed 31 characters. This was recently brought to my attention by a bug[2] from someone who actually cares because he uses the ODS-2 filesystem on OpenVMS. On a lark, I hacked the inspect tool to check for too-long filenames and lo! found a bazillion. Most (but not all) violations are from doc files auto-generated by doxygen and docbook, but which nevertheless go out with the boost distribution and so should conform. (Right?)
So, should we care? Considering that we have little control(?) over how doxygen and docbook generate their files? I have fixed the bug in question, but it feels like a token effort. Should we just drop support for niche filesystems like ODS-2, and close all future bugs "won't fix"?
[1] http://www.boost.org/development/requirements.html [2] https://svn.boost.org/trac/boost/ticket/6196
Hello, I'm the one who filed the bug. I agree that ODS-2 is a niche filesystem also because it already has the successor ODS-5. ODS-5 supports longer filenames. Sadly, changeover to ODS-5 is still on the todo-list in our company. Anyway, here are my arguments for limiting the filename length to 39 (or less) characters: 1. The file for the bug in question was the only header file in the huge boost project which was longer than 39 characters. It is now shortened, so all header files are OK for ODS-2. So there is only an effort in checking new or changed files to obey the rules. (I didn't check other files than header files). 2. There are still many people who like there source code lines to be shorter than 80 characters. Longer filenames will lead to longer include directives. It would be no problem for me if the documentation files would be too long. Working with a niche OS, I'm already happy if a third party software compiles out of the box. Best regards, Christian
participants (10)
-
Beman Dawes -
Christian Matuszewski -
Daniel James -
Dave Abrahams -
Eric Niebler -
Felipe Magno de Almeida -
Iain Denniston -
Kim Barrett -
Paul A. Bristow -
Steven Watanabe