Re: zgetcwd patch?

["John M. Harres" <harres@xxxxxxxx>]

On Sun 17 Aug 1997, Bart Schaefer wrote:

> It doesn't look wrong to me, but I'm not sure why it wasn't used in the
> first place, so I can't say for certain.  My guess is that there was an
> assumption of at most one mount of the same device in any given directory,
> so the second loop is (before your patch) finding any mount point matching
> the device and assuming that must be the one.
> 
> Why is it, again, that de->d_ino != sbuf.st_ino for the dir in question?

I'm not sure.  I originally made the test de->d_ino == ino instead of 
sbuf.st_ino == ino, and this made both loops the same, thus either both failed
or both succeeded.  I decided to try the second, since the info was there as
well, and it worked.

> 
> } I'm also curious under what circumstances these two operations differ (asid
> e
> } from the obvious chdir side effect):
> } 
> } 1. opendir( ".." );
> } 
> } 2. chdir( ".." );
> } 	opendir( "." );
> 
> It could have something to do with crossing NFS mount points.  I can't
> figure out precisely what, though, as I don't have any NFS-mounted
> filesystems to try it on.
> 
> More likely, though, it's just expediency.  The chdir("..") is done so
> that lstat() can be called directly on de->d_name.  There's probably no
> reason that
> 	closedir(dir);
> 	dir = opendir(".");
> could not be replaced by
> 	rewinddir(dir);
> unless maybe there's some implementation of the directory library out
> there that doesn't have rewinddir().

I'm almost convinced that the second loop could be avoided with some careful
if'ing.  On the other hand, the first loop may be to handle the most common
case, and the second to handle that rare case that was biting me.  This might
save performance-wise, as it skips the lstat in most cases, only resorting to
it if it fails to find the current directory without it.

At this point, I'm satisfied leaving it alone, since it works.

Thanks!
John