denny@tss.com (Denny Page) (07/09/90)
When you are in a directory which is mounted via nfs, and the inode of the current directory is > 65535 (such as on a sun), /bin/pwd reports "read error in .." Getcwd() uses /bin/pwd to do its work, and as such doesn't function. Is anyone aware of a fix or a work around for this?
dougm@ico.isc.com (Doug McCallum) (07/09/90)
In article <DENNY.90Jul8193643@atlas.tss.com> denny@tss.com (Denny Page) writes: >When you are in a directory which is mounted via nfs, and the inode of >the current directory is > 65535 (such as on a sun), /bin/pwd reports >"read error in .." Getcwd() uses /bin/pwd to do its work, and as such >doesn't function. Is anyone aware of a fix or a work around for this? This is a difficult problem to work around. AT&T changed internal inode numbers to long's but left the "stat" system call version of the inode number a short. Just changing it and rebuilding the world would solve the problem but would then break every application that comes from somewhere else. Fixes have to be made such that they are compatible with previous systems and systems from other vendors. I expect that some 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.
guy@auspex.auspex.com (Guy Harris) (07/10/90)
>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.
cpcahil@virtech.uucp (Conor P. Cahill) (07/11/90)
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
rmf@media.uucp (Roger Fujii) (07/11/90)
dougm@ico.isc.com (Doug McCallum) writes: >In article <DENNY.90Jul8193643@atlas.tss.com> denny@tss.com (Denny Page) writes: >>When you are in a directory which is mounted via nfs, and the inode of >>the current directory is > 65535 (such as on a sun), /bin/pwd reports >>"read error in .." Getcwd() uses /bin/pwd to do its work, and as such >>doesn't function. Is anyone aware of a fix or a work around for this? >This is a difficult problem to work around. AT&T changed internal inode >numbers to long's but left the "stat" system call version of the inode >number a short. Just changing it and rebuilding the world would solve >the problem but would then break every application that comes from >somewhere else. Fixes have to be made such that they are compatible >with previous systems and systems from other vendors. I expect that >some 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. Ahhh.... Someone else found this too.... Solution: 1) Fix /bin/pwd (see the bsd getpwd). I have it somewhere.... Unfortunatly, there is a lose if there just happens to be two files in the same directory with the inode numbers separated by 2^16 or greater. 2) Patch /bin/sh to disable the builtin pwd (change it to owd) -- Roger Fujii - Media Cybernetics Phone: (301)495-3305 Internet: rmf%media@uunet.uu.net UUCP: {uunet,hqda-ai}!media!rmf
strick@osc.com (henry strickland) (07/11/90)
Denny@tss.com (Denny Page) writes: >When you are in a directory which is mounted via nfs, and the inode of >the current directory is > 65535 (such as on a sun), /bin/pwd reports >"read error in .." Getcwd() uses /bin/pwd to do its work, and as such >doesn't function. Is anyone aware of a fix or a work around for this? Then it sounds like an easy fix: just rewrite /bin/pwd (seems like you understand what it takes to do that). If all your applications didn''t fork /bin/pwd, you''d be hosed. I reverse engineered (for the most part) the algorithm used in sunos4''s getwd() command by writing a tiny program something like #include <sys/param.h> char pathname[MAXPATHLEN]; char *getwd(); extern errno; main() { char *cp= getwd(pathname); if ( cp ) return printf("getwd: ``%s''\n", pathname), 0; else return printf("getwd: ERROR: %s\n", pathname), errno; } and then set gdb breakpoints (don''t forget -Bstatic) at all your favorite man 2 calls: open close creat read write stat lstat fstat opendir readdir etc. and run the program. Something like "display (char*) ($fp+4)" on a 68k will display the first arg of each system call, often a filename. I was surprised to see it open and read "/etc/mtab". Nice hack. strick.
guy@auspex.auspex.com (Guy Harris) (07/12/90)
>I think the original poster was...
The original poster was also saying that they'd be doing some sort of
fix; I was just noting what S5R4 did, so that they didn't do anything
that would collide with what it did.