[comp.sys.hp] Long filenames on HPUX 6.2

mathieu@yunexus.UUCP (Pierre Mathieu) (10/10/89)

I have been experiencing difficulties with programs that 
expect long filenames (greater than 14 characters). I am
therefore considering converting our system to long
filenames. Before I do this however, I would like to
hear from people who have done it on their systems
(since the process is not reversible, except by restoring
the system from a archival backup)
and whether it has created problems running HPUX software
or other non-HP software such as Emacs, TeX82, etc...

Thanks for any help on this matter,


-----
			   
Pierre Mathieu            
CRESS, York University,  
Ontario, Canada         
mathieu@nexus.yorku.ca 

milburn@me10.lbl.gov (John Milburn) (10/11/89)

In article <4243@yunexus.UUCP> mathieu@yunexus.UUCP (Pierre Mathieu) writes:
>therefore considering converting our system to long
>filenames. Before I do this however, I would like to
>hear from people who have done it on their systems

We did this as soon as it was possible, and have experienced no ill
effects.  If you intend to integrate hp-ux machines into a nfs
environment including servers from other vendors, it is imperative that
you change.

It was necessary to recompile some of our own code (originally compiled
with 5.x libraries) using the 6.x libs, but this is a good idea anyway.

Also, we found that for some code (PD and freeware) it may be necessary
to bugger some of the standard traps people put in for sysV or rather,
non BSD, machines, restricting filename lengths.

Overall, the conversion was quite painless, and communication with our
bsd based machines is much more pleasant. 

-jem
John Milburn - Advanced Light Source - Lawrence Berkeley Laboratory
INTERNET: JEMilburn@lbl.gov   BITNET:    JEMilburn@LBL.bitnet
UUCP:      {...}!ucbvax!lbl.gov!JEMilburn
SnailMail: 1 Cyclotron Road 46-161 Berkeley, Ca. 94720  Ph:  (415) 486-6969

irf@kuling.UUCP (Bo Thide') (10/11/89)

In article <4243@yunexus.UUCP> mathieu@yunexus.UUCP (Pierre Mathieu) writes:
>I have been experiencing difficulties with programs that 
>expect long filenames (greater than 14 characters). I am
>therefore considering converting our system to long
>filenames. Before I do this however, I would like to
>hear from people who have done it on their systems
>(since the process is not reversible, except by restoring
>the system from a archival backup)
>and whether it has created problems running HPUX software
>or other non-HP software such as Emacs, TeX82, etc...

We run HP-UX 6.5 on our 9000/300 machines and 3.1 on our 800s.
On all these machines we have changed to 255 char file names.
The only problem we had was that uugetty on the 835 did'nt recognize a
lock file that was more than 14 chars long.  This was due to very
unusual choice of name for modem /dev files (not recommended!). 
If you stick to the standard tty, cua, and cul syntax you're safe
(and do not brake other programs).

In fact, on my 370 I still have short filenames on two of the disks
(file systems) since that is still required for the other operating
systems I use (you can have up to 16 different OSs in each HP
file system).  Otherwise I would have changed those file system to
long names too.  The file system on the 370 that has long file names
is being NFS exported.

--Bo


   ^   Bo Thide'--------------------------------------------------------------
  | |       Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
  |I|    [In Swedish: Institutet f|r RymdFysik, Uppsalaavdelningen (IRFU)]
  |R|  Phone: (+46) 18-403000.  Telex: 76036 (IRFUPP S).  Fax: (+46) 18-403100 
 /|F|\        INTERNET: bt@irfu.se       UUCP: ...!uunet!sunic!irfu!bt
 ~~U~~ -----------------------------------------------------------------sm5dfw


tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (10/12/89)

>> therefore considering converting our system to long
>> filenames. Before I do this however, I would like to
>> hear from people who have done it on their systems
> 
> We did this as soon as it was possible, and have experienced no ill
> effects.  If you intend to integrate hp-ux machines into a nfs
> environment including servers from other vendors, it is imperative that
> you change.

I've heard it's more desirable to `newfs -L` your disk from the 
start, rather than convert it later to long file names.  Not sure
why people were saying this.  Just thought I'd pass that on,

> John Milburn - Advanced Light Source - Lawrence Berkeley Laboratory

Thomas Gilg
tomg@cv.hp.com

wayne@dsndata.uucp (Wayne Schlitt) (10/12/89)

In article <4243@yunexus.UUCP> mathieu@yunexus.UUCP (Pierre Mathieu) writes:
>
> [ ... ] I am therefore considering converting our system to long
> filenames. Before I do this however, I would like to
> hear from people who have done it on their systems
> [ ... ]
> and whether it has created problems running HPUX software
> or other non-HP software such as Emacs, TeX82, etc...
                                   ^^^^^

we converted to long file names as soon as we could.  the _only_
problem that we have run into is that ar will truncate the filenames
that you add to libraries to 14 characters, but when you try to
replace a member, it compares against the full filename.  this leaves
two (or more) copies of the same file in the library.  not good.

on the whole, it has probably _saved_ us from problems since we no
longer have to worry about emacs creating tilde (backup) files with
the same name as the original.  it is also nice to be able to compress
an entire directory without having to worry about the filenames being
too long with the .Z's added on.

i would say that after using long file names for a while, our average
number of characters per filename hasnt changed much.  it's just that
you no longer _have_ to make short names.  


-wayne

garvey@cmic.UUCP (Joe Garvey) (10/12/89)

In article <4243@yunexus.UUCP>, mathieu@yunexus.UUCP (Pierre Mathieu) writes:
> I have been experiencing difficulties with programs that 
> expect long filenames (greater than 14 characters). I am
> therefore considering converting our system to long
> filenames. Before I do this however, I would like to
> hear from people who have done it on their systems

I've had quite a bit of discussion with various employees of HP's about long
filenames. Here's what I know (right or wrong). I run 9000/370/360's.

Long filenames were introduced for people that REALLY needed it to work with
some other systems/widgets. Many HP tools HAVE NOT been ported/tested to work
with long filenames. On the HPUX list sccs and rcs are NOT SUPPOSED TO WORK
ON A LFN SYSTEM. I don't know if there are others. My bet is yes. ME10 (unless
you have 3.XX) will not work with LFNs. 64000UX tools may work with LFNs, but
the folks at HP "don't know the consequences of various 64000 applications
when they encounter a file name longer than 14 characters." (Quote is from
correspondence I've had with HP about the subject). It turns out this is the
basic attitude of most of HP right now. Given time, I'm sure things will
smooth out, but right now the basic attitude is "YOU ARE ON YOUR OWN IF
YOU CONVERT TO LONG FILENAMES!". I'm not a full time sysop. I can't afford
time to fool with the system fixing problems. They're bound to come up,
a large body of software hasn't been written for LFNs, much less recompiled.
None of the divisions (to the best of my knowledge) do anything before new
features are released to the public... even though they have inside knowledge
and prior access to releases. Thus no software had any chance of being ported
to a LFN system until 6.2 was released at the beginning of the year. It probably
won't be until the end of next year that all products have been recompiled for
LFN's, and that assumes it makes the schedule of changes planned.

The best you'll get offered is the fact that if you keep your filenames to
14 characters things should work... then what's the point of converting?
Aaargh.

I sincerely hope this system gets revamped, considering the merging with
Apollo and OSF. The folks that do the operating system put in changes faster
than the rest of the company seems capable of adapting. I guess I'd rather
have it than not, but don't tell the world... just tell those who need it,
and explain, very carefully, what the limitations are.

I needed LFNs to load framemaker. My solution was to go with a mixed disk
system. Fortunately, I had to buy my way slowly into HP and unix. I started
out with some small disks...  that I still have. Finally found a use for one.
I converted it to LFNs and put framemaker on it. It seems to be working ok,
so far. Not much happens to it, except it gets read. I was particularly
worried about the install, since it gets copied to the /system directory
first... must'a been a tar or cpio archive so it didn't matter. Glad HP
thought of that. :-)

Don't be suprised if the Response Center (do you use it?) gives you "NOT
A SUPPORTED CONFIGURATION" if you call'm... though I must admit... they
usually will tackle a problem of this nature even if it isn't supported.
Thanks guys.

> (since the process is not reversible, except by restoring
> the system from a archival backup)

BTW... I really doubt you could restore from an archive backup after converting.
My bet is you'd need your recovery system. Then reformat the drive to short
file names, and then use your archive backup. (Is mkfs on the recovery
system, is newfs and /etc/disktab?)

Hope this helps.

--

Joe Garvey                UUCP: {uunet,backbone}!amdahl!pyramid!mips!cmic!garvey
California Microwave      Internet: {ames}!mips!cmic!garvey
990 Almanor Ave
Sunnyvale, Ca, 94086      408-720-6439 (let it ring)

We finally made it the maps! However, I'll bet your sysop hasn't had a chance
to rebuild the map database yet.

nick@bischeops.UUCP (Nick Bender) (10/13/89)

In article <3935@helios.ee.lbl.gov>, milburn@me10.lbl.gov (John Milburn) writes:
> In article <4243@yunexus.UUCP> mathieu@yunexus.UUCP (Pierre Mathieu) writes:
> >therefore considering converting our system to long
> >filenames. Before I do this however, I would like to
> >hear from people who have done it on their systems
> 
> We did this as soon as it was possible, and have experienced no ill
> effects.  If you intend to integrate hp-ux machines into a nfs
> environment including servers from other vendors, it is imperative that
> you change.
> 

We also did this on our HPs since we also have Suns and a Pyramid.
Unfortunately some utilities didn't grok long names. The specific
instance I uncovered is that ar only handles 14 char filenames.

Example:

% cat main.c
main ()
{
  func ();
}
% cat longlonglonglong.c
#include <stdio.h>

func ()
{
  printf ("one\n");
}

% cc -c longlonglonglong.c
% cc -c main.c
% ar rv libnew.a longlonglonglong.o
a - longlonglonglong.o
ar: creating libnew.a
% cc -o main main.o libnew.a
% ./main
one
% ar vt libnew.a
rw-r--r--   214/    20    160 Oct 12 17:00 1989 longlonglonglo
% vi longlonglonglong.c
....
% cat longlonglonglong.c
#include <stdio.h>

func ()
{
  printf ("two\n");
}
% cc -c longlonglonglong.c
% ar ruv libnew.a longlonglonglong.o
a - longlonglonglong.o
% ar tv libnew.a
rw-r--r--   214/    20    160 Oct 12 17:00 1989 longlonglonglo
rw-r--r--   214/    20    160 Oct 12 17:06 1989 longlonglonglo
% cc -o main main.o libnew.a
% ./main
one
%

Nice, huh? Not only do you get the wrong module, but the library size
would grow indefinately.

[Hey HP: this is still broken under 6.5. Will it be fixed for 7.0?]

After this little gotcha I didn't bother testing RCS & SCCS, but I would
bet they break also.

-Nick

rer@hpfcdc.HP.COM (Rob Robason) (10/13/89)

> I've heard it's more desirable to `newfs -L` your disk from the 
> start, rather than convert it later to long file names.  Not sure
> why people were saying this.  Just thought I'd pass that on,

I don't think there's any reason to propogate this misconception.
Convertfs works fine.  You need to read the HP-UX reference entry before
using it, though.  I've been using long file names for a long time now
and the only problem is when I find myself on a short filename system
occasionally.

The one risk I know of is the transfer of multiple longname files to a
shortname filesystem when the first 14 characters of the filenames are
identical, causing overwriting of all but the last file, this is
preventable with due caution, and argues for converting a whole system
and site at once.

Rob Robason

al@cs.strath.ac.uk (Alan Lorimer) (10/13/89)

This disussion of long filenames is quite interesting, We converted to
LFNs about a year ago, in fact as soon as 6.2 came out. It never
crossed our minds that there would be any problems running with
HP64000, HP DesignCenter, Teamwork etc, and indeed we have had none.
We had long file names before HP supported them, since most of our
user's file stores were NFS mounted from a sequent machine (4.2 BSD)
which naturally supported LFNs. We didn't find any HPUX comand which
didn't know how to cope!

One little problem which has arisen is in the X11 include files, where
some of the file names had been truncated by the 14 char system, and
of course didn't have the `.h' on the end when accessed by the LFN
method (in particular note: mit-copyright.h)


Regards,

Alan.
____________________________________________________________________________
Alan G. Lorimer, Strathclyde University, 26 Richmond Street, Glasgow G1 1XH.
UUCP: ...!uunet!mcvax!ukc!strath-cs!al    DARPA: al%cs.strath.ac.uk@ucl-cs
					   JANET: al@uk.ac.strath.cs

dpb@orac.UUCP (Don Bennett) (10/14/89)

> We also did this on our HPs since we also have Suns and a Pyramid.
> Unfortunately some utilities didn't grok long names. The specific
> instance I uncovered is that ar only handles 14 char filenames.
> ... 
> After this little gotcha I didn't bother testing RCS & SCCS, but 
> I would bet they break also.

RCS still doesn't know about long file names, (at least as of 6.5)
but you can get source from Purdue and build a version that does.


   Don Bennett           (408)433-3311
   dpb@frame.com
   Frame Technology

jack@hpindda.HP.COM (Jack Repenning) (10/14/89)

If you presently have a short-name system, and have stuff on it that
includes some long names (which therefore got truncated when you
installed them), and convert the fs, you may have to rename those
files to their proper names.

Example.  We had a file named:

		    /usr/include/X/mit-copyright.h

as in X10 - the X11 version is named merely "copyright.h".  I'm not
sure whether this was HP product or straight off the MIT tape.

On a short-name system, this is named merely "mit-copyright.".  But,
"#include <X/mit-copyright.h>" works, because the file system knows
that's probably what you really meant (it only looks at the first 14
characters, because that's all there is).

However, when you convert this fs, the same #include doesn't work -
the filesystem sees that there's enough room for the "h", and it's not
there, so this must be the wrong file.

A simple rename or ln works fine.  Or, if you like to work yourself to
death, you can reinstall the product, which will get you a new,
properly named copy of the file.

Obviously, this sort of thing is conceivalbe for almost any file.  But
anything you got from HP is probably already named in 14-characters;
it would be stuff you got from other sources that might choke.
 

-------------------------------------------------------------
Jack Repenning - Information Networks Division,
		 Hewlett Packard Company
uucp:   ... {allegra,decvax,ihnp4,ucbvax} !hplabs!hpda!jack
  or:   ... jack@hpda.hp.com
HPDesk: Jack REPENNING  /HP6600/UX
USMail: 43LN; 19420 Homestead Ave; Cupertino, CA  95014
Phone:  408/447-3380                     HPTelnet: 1-447-3380
-------------------------------------------------------------

smp@hpfcdc.HP.COM (Steve Platt) (10/14/89)

> Long filenames were introduced for people that REALLY needed it to work with
> some other systems/widgets. Many HP tools HAVE NOT been ported/tested to work
> with long filenames. On the HPUX list sccs and rcs are NOT SUPPOSED TO WORK
> ON A LFN SYSTEM. I don't know if there are others. My bet is yes.


    As of 7.0, both SCCS and RCS support long filename systems.  If you
    know of any core commands that don't, please let us know.  Apart from
    special backward compatability issues, all core commands should work
    with long filename systems.
    	
    Steve Platt

mjs@hpfcso.HP.COM (Marc Sabatella) (10/14/89)

>Unfortunately some utilities didn't grok long names. The specific
>instance I uncovered is that ar only handles 14 char filenames.
>...
>[Hey HP: this is still broken under 6.5. Will it be fixed for 7.0?]

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.

>Nice, huh? Not only do you get the wrong module, but the library size
>would grow indefinately.

If you truncate the filename argument before adding it to the archive, it
gets replaced as you would expect.  In fact, the only thing you cannot do
it maintain an archive in which filenames are not actually significant in the
first 14 characters.

--------------
Marc Sabatella
HP Colorado Language Lab (CoLL)
marc@hpmonk

sartin@hplabsz.HPL.HP.COM (Rob Sartin) (10/15/89)

In article <3593@frame.UUCP> dpb@orac.UUCP (Don Bennett) writes:
>RCS still doesn't know about long file names, (at least as of 6.5)
>but you can get source from Purdue and build a version that does.

How very strange.  My RCS on 6.5 does understand long filenames.  As far
as I know I'm not running unsupported software (my RCS revs are the same
as found on a series 800 that installed from product tapes).  If I try
the same thing on a short filename file system I get:

ci error: RCS filename, abcdefghijklmnopqrstuvqxyz,v, is too long. Please resolve
ci aborted

I don't work on the HP-UX product, so don't take my statements as
official word from HP.

# Beginning of log
$ uname -a
HP-UX hplrds 6.5 B 9000/370 hplrds
$ touch abcdefghijklmnopqrstuvqxyz
$ ci -u abcdefghijklmnopqrstuvqxyz < /dev/null
abcdefghijklmnopqrstuvqxyz,v  <--  abcdefghijklmnopqrstuvqxyz
initial revision: 1.1
done
$ ll abc*
-r--r--r--   1 sartin   general        0 Oct 14 12:23 abcdefghijklmnopqrstuvqxyz
-r--r--r--   1 sartin   general      205 Oct 14 12:23 abcdefghijklmnopqrstuvqxyz,v
$ ident `whence rcs ci co`
/usr/bin/rcs:
     $Revision: 51.2 $
     $Header: RELEASE.h,v 62.1 88/08/20 12:36:43 runyan Exp $
     $Header: rcsedit.c,v 51.2 87/07/14 18:32:45 lacy Exp $
     $Header: rcsgen.c,v 38.2 87/07/16 15:33:20 lacy Exp $
     $Header: rcslex.c,v 4.1 85/08/14 15:52:05 scm HP_UXRel2 $
     $Header: rcsrev.c,v 51.1 87/07/08 16:15:29 runyan Exp $
     $Header: rcssyn.c,v 38.1 87/02/20 16:53:45 jvm Exp $
     $Header: rcsutil.c,v 4.3 86/02/19 08:55:18 bob Exp $

/usr/bin/ci:
     $Revision: 62.1 $
     $Header: RELEASE.h,v 62.1 88/08/20 12:36:43 runyan Exp $
     $Header: rcsedit.c,v 51.2 87/07/14 18:32:45 lacy Exp $
     $Header: rcsfcmp.c,v 38.1 87/02/20 17:01:52 jvm Exp $
     $Header: rcsgen.c,v 38.2 87/07/16 15:33:20 lacy Exp $
     $Header: rcskeep.c,v 38.1 87/02/20 16:57:18 jvm Exp $
     $Header: rcslex.c,v 4.1 85/08/14 15:52:05 scm HP_UXRel2 $
     $Header: rcsrev.c,v 51.1 87/07/08 16:15:29 runyan Exp $
     $Header: rcssyn.c,v 38.1 87/02/20 16:53:45 jvm Exp $
     $Header: rcsutil.c,v 4.3 86/02/19 08:55:18 bob Exp $

/usr/bin/co:
     $Revision: 56.1 $
     $Header: RELEASE.h,v 62.1 88/08/20 12:36:43 runyan Exp $
     $Header: maketime.c,v 4.2 85/08/14 15:51:00 scm HP_UXRel2 $
     $Header: partime.c,v 4.1 85/08/14 15:51:12 scm HP_UXRel2 $
     $Header: time.h,v 4.1 85/08/14 15:49:01 scm HP_UXRel2 $
     $Header: rcsgen.c,v 38.2 87/07/16 15:33:20 lacy Exp $
     $Header: rcslex.c,v 4.1 85/08/14 15:52:05 scm HP_UXRel2 $
     $Header: rcsrev.c,v 51.1 87/07/08 16:15:29 runyan Exp $
     $Header: rcssyn.c,v 38.1 87/02/20 16:53:45 jvm Exp $
     $Header: rcsutil.c,v 4.3 86/02/19 08:55:18 bob Exp $
     $Header: rcsedit.c,v 51.2 87/07/14 18:32:45 lacy Exp $

$ 
# End of log

Rob Sartin			internet: sartin@hplabs.hp.com
Software Technology Lab 	uucp    : hplabs!sartin
Hewlett-Packard			voice	: (415) 857-7592

frank@zen.co.uk (Frank Wales) (10/18/89)

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 

mjs@hpfcso.HP.COM (Marc Sabatella) (10/25/89)

>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.

This is certainly true, we could have "ar" and even "ld", "nm", and all other
related tools know about the change.  The problem as I perceive it is changing
a documented file format is considered a no-no, as people out there have
written their own code (yes they have) which know file formats.

In any case, the combination of "difficult to do" + "breaks user code which
depends on our documented file formats" + "workaround trivial" adds up to
"will not fix".

--------------
Marc Sabatella
HP Colorado Language Lab (CoLL)
marc@hpmonk