[lmi] 31-character file-name limit

[Greg Chicares]

[off-list message quoted by permission]

On 2014-10-12 21:50Z, Vadim Zeitlin wrote:
[...]
> File 'wx_test_about_dialog_version.cpp' exceeds 31-character file-name limit.
> 
> I'd really like to avoid renaming this file, both because its current name
> is nicely descriptive and I would either have to lose this or use "dlg"
> instead of "dialog", which would be inconsistent with the existing files
> called "about_dialog.[ch]pp", and also because I'd like to keep it history,
> at least locally, and while git is smart about renaming, it's still simpler
> not to do it unless really necessary.

Noted; I'll return to that below.

>  And I have to wonder whether it is, because this 31 character limit seems
> quite arbitrary to me. Looking at the various file systems at
> 
>       http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
> 
> I see exactly one of them imposing such limit, and this is the completely
> obsolete HFS which was only ever used by Apple machines not targeted by
> LMI anyhow (well, there is also another one called PramFS, but I'm pretty
> sure that a file system I've never so much as heard about should not enter
> into practical consideration). So where does this come from and could this
> limit be relaxed to be at least 32 (which happens to be the length of the
> name of this particular file) or maybe even 64 or 128, as there doesn't
> seem to be any technical reason to disallow even longer file names?

It originally came from an old boost.org guideline. I like limits in general:
they force us to say more in less space.

We can keep everything nicely descriptive by changing the prefix, e.g.:
            11111111112222222222333
  123456789012345678901234567890123
- wx_test_about_dialog_version.cpp
+ wxt_about_dialog_version.cpp
- wx_test_configurable_settings.cpp
+ wxt_configurable_settings.cpp
and thus consistently for all the pending new files. (It seems okay NOT
to rename anything that's in today's HEAD (revision 5984), thus retaining
'main_wx_test.cpp' and names in makefiles like 'wx_test$(EXEEXT)'.

As for the particular limit of 31, see:
  http://lists.boost.org/Archives/boost/2004/08/70246.php
which says it's the real maximum for ISO9660 Level 2. The wikipedia article
you cited says otherwise, so I googled a little and found quite a variety of
answers from seemingly-credible sources; I guess the operative answer depends
on the operating system and perhaps the hardware.

Other messages in that boost discussion say that CDs would normally be used
for compressed archives, so that such a restriction may be unnecessary on
names of source files. And I realize that in this decade it's no longer
common for computers to have CD drives. So I was initially leaning toward
increasing that limit by a few characters, just this once...but then I asked
myself: when was the last time I wrote a non-archived source file to a CD?
The answer is "last month", to get a crucial change to my coworkers when
my modem died. I don't know whether that would have worked with a longer
filename. There's only one computer in the office that still has a CD
drive, and it's probably old; I don't know what variant of ISO 9660 it
supports. What I am sure is that we've followed a 31-character maximum and
never had a problem. I'm reluctant to give up that assurance.

How much 'git' trouble does renaming actually create? Consider this file:
  
http://svn.savannah.nongnu.org/viewvc/lmi/trunk/lmi_msw_res.rc?root=lmi&view=log
which was renamed on 20110623T1036Z--but its entire history is shown by
viewvc, and by '$svn log lmi_msw_res.rc'. I assume git's at least as good,
but I imagine you use more of git's capabilities than I do of svn's, so I
want to be sure I'm not overlooking some major hassle.