Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.internals Subject: Re: Help! modifying os to support >14 char filenames (sys V.3) Message-ID: Date: 21 Sep 90 13:21:46 GMT References: <1430@engadm2.csd.mot.com> <8738@orca.wv.tek.com> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 81 Nntp-Posting-Host: odin In-reply-to: machina@uts.amdahl.com's message of 19 Sep 90 06:18:17 GMT On 19 Sep 90 06:18:17 GMT, machina@uts.amdahl.com (Miguel A. Ramirez) said: [ ... on how many user programs have an hard coded 14 for the max length of file name in a System V environment, and thus would not respond to a change in a #define ... ] machina> There's no such thing as an easy hack. Indeed, being able to change a #define'd symbol from 14 to 30 is not an easy hack, and I have been only been trying to sound funny; much more seriously, it is the reason why the #define'd symbol has been there since at least 10 years ago, to allow for *easy* parametrization. Some user programs have been silly enough to avoid it? They would break under *any* scheme to change the filename length, so changing the #define is the _easiest_ way out, because at least it impacts the kernel and kernel-level utilities less than the other choices. Once you have decided you want to change the maximum file name length, what is 'easy' is relative to that decision. Maybe I should have written 'an easy (relative to the other alternatives) way to satisfy your requirement in a strict sense and with the easiest and smallest (relatively, but also, to me, in absolute terms) changes to kernel and command sources is ...' instead of 'an easy hack is ...'. My postings are already too long -- I don't really want to write out everything in extenso, just to avoid people like you getting confused. News is not Congress (yet :->), and articles are not Bills. machina> BTW, Piercarlo did you test not only the kernel but also all machina> the commands that were effected by the long file name support? Actually, I think I have listed most of those in the standard System V distribution (I think I forgot SCCS, and no doubt some others) in some past article. Let me repeat, very few programs actually scan directories. Most work on collections of file pathnames, and of these only a few break a file pathname in file names (most are happy with mucking with suffixes at the end of pathnames). One may want to have a look at the BSD sources (freely available to those that have a System V source license) and scan them for usage of MAXNAMLEN; one would easily find the list of programs (modulo some BSD vs. System V differences) where one has to become suspicious, because the BSD crew put in all those MAXNAMLENs when they had to convert from the V7/V32/4.1BSD/System III/System V to the FFS directory organization. machina> No? But I thought it was an easy hack? -- You seem so sure, you must have done so. So please, for our information, post a list of commands and libraries in the standard System V distribution that have an hard coded 14, the relative percentage of source files, and in how many places for each. Also, what is easy depends on many factors; what is easy for me may be a big problem to you, for example, or (improbably :->) viceversa. For me using find(1), xargs(1) and egrep(1) is easy, for example, and not even too time consuming :-) :-) :-). The difficult problems are others even if somebody may seem daunted by the consequences of changing a fairly old and well understood symbolic constant. As to the real problems, another example; from evidence easily available using any AT&T, Sun or Dec (just to mention three big names) UNIX kernel, doing trivial tuning or even just avoiding gross misdesigns of page (and working set) replacement kernel modules and of the programs that run under them seems to be impossibly difficult (for those manufacturers, at least) or to require an inordinate number of releases. (spoiler: actually paging or swapping module design is not an easy task for anybody, especially if compared with merely changing the file name length leaving the directory structure the same. It is a bit easier though than what would be apparent from the problems that AT&T, Sun and Dec (and many others) seem to have with it). -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk