Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!quest!digibd!rhealey From: rhealey@digibd.com (Rob Healey) Newsgroups: comp.unix.sysv386 Subject: Re: SCO's V.4 plans Message-ID: <1990Nov29.204318.3337@digibd.com> Date: 29 Nov 90 20:43:18 GMT References: <1990Nov15.225728.16481@cbnewsm.att.com> <152@raysnec.UUCP> <1990Nov26.194751.24747@ico.isc.com> Organization: Digiboard Incorporated, St. Louis Park, MN Lines: 22 In article <1990Nov26.194751.24747@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >> As I recall from an SCO presentation at our user group last December, >> their stated inclination is to enhance 3.2 with those components or features >> from V.4 most in demand... >Interesting idea, but could someone explain how this works without giving >you a result which is neither fish nor fowl? The best example I know of is >long file names in a BSD-like file system; it may well be the single most- >often-requested BSD feature. But if you create a modified file system with >long file names, it's *going* to be incompatible, no getting around it. At >that point, you're no longer a V.3.2 system, period. How do you do this? >Anyone from SCO, or who's heard what SCO claims, want to explain this? > Might create a BSD file system like ESIX has done. Might not be the cleanest solution but it would allow for longer file names amongs other things. This seems like a fairly obvious answer considering the FSS. Why won't this idea work? I'm sure ESIX would love to know... -Rob Speaking for self, not company.