|
Boost : |
Subject: Re: [boost] [guideline] 31 character filenames?
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2012-03-28 09:52:53
On Wed, Mar 28, 2012 at 10:50 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
> On Wed, Mar 28, 2012 at 4:44 AM, Paul A. Bristow
> <pbristow_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk