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