Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!mcsun!ukc!edcastle!hwcs!zen!frank
From: frank@zen.co.uk (Frank Wales)
Newsgroups: comp.sys.hp
Subject: Re: Long filenames on HPUX 6.2
Message-ID: <1733@zen.co.uk>
Date: 18 Oct 89 13:32:18 GMT
References: <4243@yunexus.UUCP> <7370015@hpfcso.HP.COM>
Reply-To: frank@zen.co.uk (Frank Wales)
Organization: Zengrange Limited, Leeds, England
Lines: 30

In article <7370015@hpfcso.HP.COM> mjs@hpfcso.HP.COM (Marc Sabatella) writes:
>>Unfortunately some utilities didn't grok long names. The specific
>>instance I uncovered is that ar only handles 14 char filenames.
>
>This has been known from the beginning, and it was decided then that this would
>not be fixed, and that decision stands.
>
>Reason: the file format would have to change to support this, and HP seems to
>value backward compatibility more than absolute functional completeness in
>every corner case.

[Hypothesis time... :-)]
Perhaps the question asked was:  "Does adding long filename support
break ar?"  when it should have been:  "We must have an archiver that
supports long filenames; how can we do it so that nothing breaks?"

The argument for backward compatibility is strong, but I have yet to
find a case where both old functionality and new couldn't be provided
*somehow*.  For example, by allowing reading of old formats but writing
of new ones by default, with options for controlling this behvaiour.  If
this can't be done compatibly without something breaking, then provide a
different command, called (say) nar ("new ar"), which expands the
feature set of ar, and brings it up to date.

There is no excuse for ignoring the past; equally, there is no excuse
for ignoring progress.  Customers should at least have the *choice* of
breaking with tradition.  
--
Frank Wales, Systems Manager,        [frank@zen.co.uk<->mcvax!zen.co.uk!frank]
Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217