Path: utzoo!attcan!uunet!virtech!cpcahil From: cpcahil@virtech.uucp (Conor P. Cahill) Newsgroups: comp.unix.i386 Subject: Re: i386 unix with NFS - getcwd() & /bin/pwd inode problem Message-ID: <1990Jul10.222527.2211@virtech.uucp> Date: 10 Jul 90 22:25:27 GMT References: <1990Jul9.142023.17830@ico.isc.com> <3632@auspex.auspex.com> Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill) Distribution: na Organization: Virtual Technologies Inc., Sterling VA Lines: 23 In article <3632@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>I expect thatsome type of fix will be made in a future release of our >>(ISC) version once we have one which will let the binary work on other >>systems that don't have the fix. > >S5R4 has "ino_t" as a long (or at least that was what I last heard - >given that the BSD file system is one of the on-disk file systems S5R4 >supports, they had to do that), with "stat()" getting a new trap number >and the old trap number giving you the old structure for binary >compatibility (just what Berkeley did in 4.2BSD, in other words). They >also added some other Berkeley fields to the "stat" structure. I think the original poster was refering to the problem that if ISC fixed thier system to have a bigger ino_t, then binaries generated on ISC wouldn't work on SCO or ESIX, etc. The "add a new system call, and save the old one for binary compatiblity" only works in a "forward compatibility motion", not a horizontal or backward motion. no -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170