* weird zsh startup behavior @ 1997-08-08 20:51 John M. Harres 1997-08-09 1:16 ` Zoltan Hidvegi 0 siblings, 1 reply; 19+ messages in thread From: John M. Harres @ 1997-08-08 20:51 UTC (permalink / raw) To: Zsh hackers list # pwd /home/lsims # zsh lanshark# pwd /home/sinclair Does anyone know under what circumstances zsh will change directory on startup? I was in root under sh, ran zsh, and zappo, switched directories, and not to root's home directory. Both home directories are automounted. Hohn Harres harres@uwyo.edu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: weird zsh startup behavior 1997-08-08 20:51 weird zsh startup behavior John M. Harres @ 1997-08-09 1:16 ` Zoltan Hidvegi 1997-08-09 4:39 ` John M. Harres 0 siblings, 1 reply; 19+ messages in thread From: Zoltan Hidvegi @ 1997-08-09 1:16 UTC (permalink / raw) To: John M. Harres; +Cc: zsh-workers > # pwd > /home/lsims > # zsh > lanshark# pwd > /home/sinclair > > Does anyone know under what circumstances zsh will change directory on > startup? I was in root under sh, ran zsh, and zappo, switched directories, > and not to root's home directory. Both home directories are automounted. We can only fix this problem if you provide more details about the problem. What zsh version, OS, OS version, libc version, compiler are you using? Can you reproduce this with zsh -f? If not, try to find the command in you startup files which triggers the problem. Zoltan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: weird zsh startup behavior 1997-08-09 1:16 ` Zoltan Hidvegi @ 1997-08-09 4:39 ` John M. Harres 1997-08-09 5:11 ` Geoff Wing 0 siblings, 1 reply; 19+ messages in thread From: John M. Harres @ 1997-08-09 4:39 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: zsh-workers On Fri 8 Aug 1997, Zoltan Hidvegi wrote: > > Does anyone know under what circumstances zsh will change directory on > > startup? I was in root under sh, ran zsh, and zappo, switched directories, > > and not to root's home directory. Both home directories are automounted. > > We can only fix this problem if you provide more details about the > problem. What zsh version, OS, OS version, libc version, compiler are > you using? Can you reproduce this with zsh -f? If not, try to find the > command in you startup files which triggers the problem. Sorry, brain on hold. zsh 3.0.4, Solaris 2.5.1, gcc-2.7.2.2, whatever libc Sun ships withe Solaris 2.5.1. Reproduced with zsh -f: # pwd /home/lsims # zsh -f lanshark:/home/sinclair# pwd /home/sinclair I've also checked to make sure both users have unique uid's and home dirs, which both do. Also, the auto_home file points correctly to two different directories. John Harres harres@uwyo.edu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: weird zsh startup behavior 1997-08-09 4:39 ` John M. Harres @ 1997-08-09 5:11 ` Geoff Wing 1997-08-09 5:58 ` John M. Harres 1997-08-10 7:30 ` Todd Larason 0 siblings, 2 replies; 19+ messages in thread From: Geoff Wing @ 1997-08-09 5:11 UTC (permalink / raw) To: zsh-workers John M. Harres <harres@UWYO.EDU> typed: :On Fri 8 Aug 1997, Zoltan Hidvegi wrote: :> > Does anyone know under what circumstances zsh will change directory on :> > startup? I was in root under sh, ran zsh, and zappo, switched directories, :> > and not to root's home directory. Both home directories are automounted. :> We can only fix this problem if you provide more details about the :> problem. What zsh version, OS, OS version, libc version, compiler are :> you using? Can you reproduce this with zsh -f? If not, try to find the :> command in you startup files which triggers the problem. :Sorry, brain on hold. zsh 3.0.4, Solaris 2.5.1, gcc-2.7.2.2, whatever libc :Sun ships withe Solaris 2.5.1. :Reproduced with zsh -f: Can you reproduce it with "zsh -f" and no /etc/zshenv? -- Geoff Wing [mason@primenet.com.au] Phone : +61-3-9818 2977 Technical Manager: PrimeNet Computer Consultants Facsimile: +61-3-9819 3788 Web: <URL:http://www.primenet.com.au/> Mobile : 0412 162 441 [ Boulderdash: <URL:http://ciips.ee.uwa.edu.au/~williams/bd/> ] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: weird zsh startup behavior 1997-08-09 5:11 ` Geoff Wing @ 1997-08-09 5:58 ` John M. Harres 1997-08-10 7:30 ` Todd Larason 1 sibling, 0 replies; 19+ messages in thread From: John M. Harres @ 1997-08-09 5:58 UTC (permalink / raw) To: mason; +Cc: zsh-workers On Sat 9 Aug 1997, Geoff Wing wrote: > John M. Harres <harres@UWYO.EDU> typed: > :On Fri 8 Aug 1997, Zoltan Hidvegi wrote: > :> > Does anyone know under what circumstances zsh will change directory on > :> > startup? I was in root under sh, ran zsh, and zappo, switched directori > es, > :> > and not to root's home directory. Both home directories are automounted > . > :> We can only fix this problem if you provide more details about the > :> problem. What zsh version, OS, OS version, libc version, compiler are > :> you using? Can you reproduce this with zsh -f? If not, try to find the > :> command in you startup files which triggers the problem. > :Sorry, brain on hold. zsh 3.0.4, Solaris 2.5.1, gcc-2.7.2.2, whatever libc > :Sun ships withe Solaris 2.5.1. > :Reproduced with zsh -f: > > Can you reproduce it with "zsh -f" and no /etc/zshenv? With no /etc/z* /.z* (I was running as root), still the same problem. Further: It seems to occur when I'm in any user's home directory who has a local home directory (as opposed to those with remote automounted home directories) as long as that home directory is automounted. I've tried it on another virtually identical system, with similar, though not quite the same, results: ghidora% su ~ Password: # cd /home/bthomas # zsh -f ghidora:/home/harres# pwd /home/harres There is no consistency with the order of the auto_home file, nor the passwd file for deriving the 'magic' user you end up in the home directory of. Let me know if there's anything else I can provide. John Harres harres@uwyo.edu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: weird zsh startup behavior 1997-08-09 5:11 ` Geoff Wing 1997-08-09 5:58 ` John M. Harres @ 1997-08-10 7:30 ` Todd Larason 1997-08-12 15:31 ` John M. Harres 1997-08-12 16:15 ` John M. Harres 1 sibling, 2 replies; 19+ messages in thread From: Todd Larason @ 1997-08-10 7:30 UTC (permalink / raw) To: mason; +Cc: zsh-workers On Sat, Aug 09, 1997 at 05:11:53AM +0000, Geoff Wing wrote: > John M. Harres <harres@UWYO.EDU> typed: > :On Fri 8 Aug 1997, Zoltan Hidvegi wrote: > :> > Does anyone know under what circumstances zsh will change directory on > :> > startup? I was in root under sh, ran zsh, and zappo, switched directories, > :> > and not to root's home directory. Both home directories are automounted. > :> We can only fix this problem if you provide more details about the > :> problem. What zsh version, OS, OS version, libc version, compiler are > :> you using? Can you reproduce this with zsh -f? If not, try to find the > :> command in you startup files which triggers the problem. > :Sorry, brain on hold. zsh 3.0.4, Solaris 2.5.1, gcc-2.7.2.2, whatever libc > :Sun ships withe Solaris 2.5.1. > :Reproduced with zsh -f: > > Can you reproduce it with "zsh -f" and no /etc/zshenv? Ack, I never wrote the list about this, did I? I saw this on a similar setup - Solaris 2.4, home directories automounted, zsh 3.0 betas I think. I no longer have access to this system, so I can't double check the details, but they're not terribly important. The problem was an assumption made in zgetcwd(), which didn't hold with the automounted home dirs. I don't seem to have the patch I made, and I'm going on foggy memory here I'm afraid. Anything that caused a zgetcwd() would end up *changing* the current directory. Looking at zgetcwd, I'm thinking that the false assumption was that only one mountpoint could have the same device number ("if (sbuf.st_dev == dev) goto match;" around lines 178-179 in 3.0.4:compat.c). With sun's automounter, with multiple directories from the same device mounted into the same directory, this wasn't true. I assume my fix was to check the inode too. Sorry this is so vague and wishy washy, but hopefully it will save some time tracking down the details. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: weird zsh startup behavior 1997-08-10 7:30 ` Todd Larason @ 1997-08-12 15:31 ` John M. Harres 1997-08-12 16:04 ` Todd Larason 1997-08-12 16:15 ` John M. Harres 1 sibling, 1 reply; 19+ messages in thread From: John M. Harres @ 1997-08-12 15:31 UTC (permalink / raw) To: Todd Larason; +Cc: mason, zsh-workers [-- Attachment #1: Type: text/plain, Size: 2126 bytes --] On Sun 10 Aug 1997, Todd Larason wrote: > On Sat, Aug 09, 1997 at 05:11:53AM +0000, Geoff Wing wrote: > > John M. Harres <harres@UWYO.EDU> typed: > > > Does anyone know under what circumstances zsh will change directory on > > > startup? I was in root under sh, ran zsh, and zappo, switched directories, > > > and not to root's home directory. Both home directories are automounted. > I saw this on a similar setup - Solaris 2.4, home directories automounted, > zsh 3.0 betas I think. I no longer have access to this system, so I can't > double check the details, but they're not terribly important. > > The problem was an assumption made in zgetcwd(), which didn't hold with > the automounted home dirs. I don't seem to have the patch I made, and I'm > going on foggy memory here I'm afraid. > > Anything that caused a zgetcwd() would end up *changing* the current > directory. > > Looking at zgetcwd, I'm thinking that the false assumption was that only > one mountpoint could have the same device number ("if (sbuf.st_dev == dev) > goto match;" around lines 178-179 in 3.0.4:compat.c). With sun's > automounter, with multiple directories from the same device mounted into > the same directory, this wasn't true. I assume my fix was to check the > inode too. Trying to look into this further, I'm getting further confused. zgetcwd() appears to do some checks, then opens '..' scanning for the directory we are (were since there's a chdir()) in. If that is not found, it then scans '.', but since we did a chdir("..") after opendir(".."), the second opendir should be opening the same directory as the first. The second directory scan does not have the inode check, as you mentioned, but if it's there, the two loops look like they should either both succeed or fail, thus the second adds nothing. What is the second loop intended to do? I also don't understand when the first loop would fail. It simply looks for the dev & ino that match "." in the dirent's for "..". What conditions will is that trying to catch? Sorry for my lack of understanding. It's my first dive into the zsh source. John [-- Attachment #2: Type: application/pgp-signature, Size: 239 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: weird zsh startup behavior 1997-08-12 15:31 ` John M. Harres @ 1997-08-12 16:04 ` Todd Larason 0 siblings, 0 replies; 19+ messages in thread From: Todd Larason @ 1997-08-12 16:04 UTC (permalink / raw) To: John M. Harres; +Cc: mason, zsh-workers On Tue, Aug 12, 1997 at 09:31:58AM -0600, John M. Harres wrote: > The second directory scan does not have the inode check, as you mentioned, but > if it's there, the two loops look like they should either both succeed or > fail, thus the second adds nothing. I'm not where I can look at the source right now, but my memory is that the second one stat()s each file as it goes along, and used the dev number from that; I'm assuming that's intended to find mounted file systems -- readdir() gives info on the directory being mounted over, stat() gives info on the mounted dir. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: weird zsh startup behavior 1997-08-10 7:30 ` Todd Larason 1997-08-12 15:31 ` John M. Harres @ 1997-08-12 16:15 ` John M. Harres 1997-08-15 13:15 ` zgetcwd patch? John M. Harres 1 sibling, 1 reply; 19+ messages in thread From: John M. Harres @ 1997-08-12 16:15 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 962 bytes --] Well, this rather trivial patch seems to work. Please let me know if there's anything I've done wrong. I'm beginning to think the second loop is intended to handle the current directory being a symlink. For that reason, I'm checking the lstat's results' inode rather than the directory entry's, although again, I'm not completely sure under what circumstances these will differ. John *** compat.c.old Tue Dec 17 13:14:11 1996 --- compat.c Tue Aug 12 09:56:21 1997 *************** *** 176,182 **** (fn[1] == '.' && fn[2] == '\0'))) continue; lstat(fn, &sbuf); ! if (sbuf.st_dev == dev) goto match; } noholdintr(); --- 176,182 ---- (fn[1] == '.' && fn[2] == '\0'))) continue; lstat(fn, &sbuf); ! if (sbuf.st_dev == dev && sbuf.st_ino == ino) goto match; } noholdintr(); [-- Attachment #2: Type: application/pgp-signature, Size: 239 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* zgetcwd patch? 1997-08-12 16:15 ` John M. Harres @ 1997-08-15 13:15 ` John M. Harres 1997-08-18 5:05 ` Bart Schaefer 1997-08-25 5:06 ` Zoltan Hidvegi 0 siblings, 2 replies; 19+ messages in thread From: John M. Harres @ 1997-08-15 13:15 UTC (permalink / raw) To: zsh-workers, harres I never heard a response to the patch I sent to compat.c. Does it appear correct? I'm also curious under what circumstances these two operations differ (aside from the obvious chdir side effect): 1. opendir( ".." ); 2. chdir( ".." ); opendir( "." ); Thanks, John Harres harres@uwyo.edu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: zgetcwd patch? 1997-08-15 13:15 ` zgetcwd patch? John M. Harres @ 1997-08-18 5:05 ` Bart Schaefer 1997-08-18 16:28 ` John M. Harres 1997-08-18 19:48 ` Todd Larason 1997-08-25 5:06 ` Zoltan Hidvegi 1 sibling, 2 replies; 19+ messages in thread From: Bart Schaefer @ 1997-08-18 5:05 UTC (permalink / raw) To: John M. Harres; +Cc: zsh-workers On Aug 15, 7:15am, John M. Harres wrote: } Subject: zgetcwd patch? } } I never heard a response to the patch I sent to compat.c. Just so you know someone's paying attention ... } Does it appear correct? 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 also curious under what circumstances these two operations differ (aside } 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(). -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: zgetcwd patch? 1997-08-18 5:05 ` Bart Schaefer @ 1997-08-18 16:28 ` John M. Harres 1997-08-18 19:48 ` Todd Larason 1 sibling, 0 replies; 19+ messages in thread From: John M. Harres @ 1997-08-18 16:28 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: zgetcwd patch? 1997-08-18 5:05 ` Bart Schaefer 1997-08-18 16:28 ` John M. Harres @ 1997-08-18 19:48 ` Todd Larason 1997-08-19 9:31 ` Bart Schaefer 1 sibling, 1 reply; 19+ messages in thread From: Todd Larason @ 1997-08-18 19:48 UTC (permalink / raw) To: Bart Schaefer; +Cc: John M. Harres, zsh-workers On Sun, Aug 17, 1997 at 10:05:53PM -0700, 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? My understanding was that the first loop would find the parent if it was in the same filesystem as the child; the second would find the place the child was mounted, in the only other case. The problem is that it was assumed that a filesystem can only be mounted one place, and that the device number identifies filesystems. In this situation, there's /home on filesystem one, /home/a and /home/b are both automounted directories from filesystem 2. for a and b, de->d_ino is the inode of the mountpoint directory in /home, in filesystem 1; sbuf.st_ino is the inode of the mounted directory, in filesystem 2. > } I'm also curious under what circumstances these two operations differ (aside > } from the obvious chdir side effect): > } > } 1. opendir( ".." ); > } > } 2. chdir( ".." ); > } opendir( "." ); These do the same thing; the only important difference is that the second lstat()s and compares that info instead of the directory info. These could be combined into one loop, but you don't really want to stat unless you have to. From zsh-workers-request@math.gatech.edu Mon Aug 18 20:21:04 1997 Return-Path: <zsh-workers-request@math.gatech.edu> Delivered-To: mason@primenet.com.au Received: (qmail 14552 invoked from network); 18 Aug 1997 20:21:02 -0000 Received: from euclid.skiles.gatech.edu (HELO euclid.math.gatech.edu) (root@130.207.146.50) by coral.primenet.com.au with SMTP; 18 Aug 1997 20:21:02 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.8.5/8.8.5) id PAA09012; Mon, 18 Aug 1997 15:50:17 -0400 (EDT) Resent-Date: Mon, 18 Aug 1997 15:50:17 -0400 (EDT) Message-ID: <19970818124801.25766@molehill.org> Date: Mon, 18 Aug 1997 12:48:01 -0700 From: Todd Larason <jtl@molehill.org> To: Bart Schaefer <schaefer@brasslantern.com> Cc: "John M. Harres" <harres@ghidora.uwyo.edu>, zsh-workers@math.gatech.edu Subject: Re: zgetcwd patch? References: <199708151315.HAA24323@ghidora.uwyo.edu> <970817220553.ZM23929@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <970817220553.ZM23929@candle.brasslantern.com>; from Bart Schaefer on Sun, Aug 17, 1997 at 10:05:53PM -0700 Resent-Message-ID: <"30PCq2.0.iC2.uTA-p"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3448 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Sun, Aug 17, 1997 at 10:05:53PM -0700, 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? My understanding was that the first loop would find the parent if it was in the same filesystem as the child; the second would find the place the child was mounted, in the only other case. The problem is that it was assumed that a filesystem can only be mounted one place, and that the device number identifies filesystems. In this situation, there's /home on filesystem one, /home/a and /home/b are both automounted directories from filesystem 2. for a and b, de->d_ino is the inode of the mountpoint directory in /home, in filesystem 1; sbuf.st_ino is the inode of the mounted directory, in filesystem 2. > } I'm also curious under what circumstances these two operations differ (aside > } from the obvious chdir side effect): > } > } 1. opendir( ".." ); > } > } 2. chdir( ".." ); > } opendir( "." ); These do the same thing; the only important difference is that the second lstat()s and compares that info instead of the directory info. These could be combined into one loop, but you don't really want to stat unless you have to. From zsh-workers-request@math.gatech.edu Tue Aug 19 00:52:25 1997 Return-Path: <zsh-workers-request@math.gatech.edu> Delivered-To: mason@primenet.com.au Received: (qmail 15686 invoked from network); 19 Aug 1997 00:52:23 -0000 Received: from euclid.skiles.gatech.edu (HELO math.gatech.edu) (root@130.207.146.50) by ns1.primenet.com.au with SMTP; 19 Aug 1997 00:52:23 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.8.5/8.8.5) id PAA09012; Mon, 18 Aug 1997 15:50:17 -0400 (EDT) Resent-Date: Mon, 18 Aug 1997 15:50:17 -0400 (EDT) Message-ID: <19970818124801.25766@molehill.org> Date: Mon, 18 Aug 1997 12:48:01 -0700 From: Todd Larason <jtl@molehill.org> To: Bart Schaefer <schaefer@brasslantern.com> Cc: "John M. Harres" <harres@ghidora.uwyo.edu>, zsh-workers@math.gatech.edu Subject: Re: zgetcwd patch? References: <199708151315.HAA24323@ghidora.uwyo.edu> <970817220553.ZM23929@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <970817220553.ZM23929@candle.brasslantern.com>; from Bart Schaefer on Sun, Aug 17, 1997 at 10:05:53PM -0700 Resent-Message-ID: <"30PCq2.0.iC2.uTA-p"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3448 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Sun, Aug 17, 1997 at 10:05:53PM -0700, 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? My understanding was that the first loop would find the parent if it was in the same filesystem as the child; the second would find the place the child was mounted, in the only other case. The problem is that it was assumed that a filesystem can only be mounted one place, and that the device number identifies filesystems. In this situation, there's /home on filesystem one, /home/a and /home/b are both automounted directories from filesystem 2. for a and b, de->d_ino is the inode of the mountpoint directory in /home, in filesystem 1; sbuf.st_ino is the inode of the mounted directory, in filesystem 2. > } I'm also curious under what circumstances these two operations differ (aside > } from the obvious chdir side effect): > } > } 1. opendir( ".." ); > } > } 2. chdir( ".." ); > } opendir( "." ); These do the same thing; the only important difference is that the second lstat()s and compares that info instead of the directory info. These could be combined into one loop, but you don't really want to stat unless you have to. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: zgetcwd patch? 1997-08-18 19:48 ` Todd Larason @ 1997-08-19 9:31 ` Bart Schaefer 0 siblings, 0 replies; 19+ messages in thread From: Bart Schaefer @ 1997-08-19 9:31 UTC (permalink / raw) To: zsh-workers On Aug 18, 12:48pm, Todd Larason wrote: } Subject: Re: zgetcwd patch? } } On Sun, Aug 17, 1997 at 10:05:53PM -0700, 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? } } My understanding was that the first loop would find the parent if it was } in the same filesystem as the child; the second would find the place the } child was mounted, in the only other case. No; both loops are looking for the child's entry in the parent. The first looks for entries with the same inode number, then uses lstat to see if the device number is also the same. If no entry has the same inode and device, the second loop uses lstat to look for any entry that has the same device number as the child. } The problem is that it was assumed that a filesystem can only be mounted } one place, and that the device number identifies filesystems. That part, I believe to be a correct description. } In this situation, there's /home on filesystem one, /home/a and /home/b } are both automounted directories from filesystem 2. } } for a and b, de->d_ino is the inode of the mountpoint directory in /home, } in filesystem 1; sbuf.st_ino is the inode of the mounted directory, in } filesystem 2. In that case I also believe John's zgetcwd patch to be correct. I think the process could be sped up a bit by replacing the closedir() + opendir() with a rewinddir(), as I mentioned before. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: zgetcwd patch? 1997-08-15 13:15 ` zgetcwd patch? John M. Harres 1997-08-18 5:05 ` Bart Schaefer @ 1997-08-25 5:06 ` Zoltan Hidvegi 1997-08-25 17:06 ` zsh-3.0.4 blessed patches (was Re: zgetcwd patch?) Mark Borges 1 sibling, 1 reply; 19+ messages in thread From: Zoltan Hidvegi @ 1997-08-25 5:06 UTC (permalink / raw) To: John M. Harres; +Cc: Zsh hacking and development > I never heard a response to the patch I sent to compat.c. > Does it appear correct? > > I'm also curious under what circumstances these two operations differ (aside > from the obvious chdir side effect): > > 1. opendir( ".." ); > > 2. chdir( ".." ); > opendir( "." ); Sorry for my silence about this. Zsh-3.1.1 already had a fix for this promlem, here is the patch for zsh-3.0.4. It avoids the double scan you noticed. Zoltan *** compat.c.3.0.4 Tue Dec 17 15:14:11 1996 --- compat.c Mon Aug 25 00:58:18 1997 *************** *** 115,122 **** struct stat sbuf; struct dirent *de; DIR *dir; ! ino_t ino, rootino = (ino_t) ~ 0; ! dev_t dev, rootdev = (dev_t) ~ 0; holdintr(); buf2[0] = '\0'; --- 115,122 ---- struct stat sbuf; struct dirent *de; DIR *dir; ! ino_t ino, pino, rootino = (ino_t) ~ 0; ! dev_t dev, pdev, rootdev = (dev_t) ~ 0; holdintr(); buf2[0] = '\0'; *************** *** 127,146 **** rootdev = sbuf.st_dev; } for (;;) { - if (stat(".", &sbuf) < 0) { - chdir(buf0); - noholdintr(); - return ztrdup("."); - } - ino = sbuf.st_ino; - dev = sbuf.st_dev; if (stat("..", &sbuf) < 0) { chdir(buf0); noholdintr(); return ztrdup("."); } ! if ((sbuf.st_ino == ino && sbuf.st_dev == dev) || (ino == rootino && dev == rootdev)) { chdir(buf0); noholdintr(); --- 127,153 ---- rootdev = sbuf.st_dev; } + if (stat(".", &sbuf) < 0) { + noholdintr(); + return ztrdup("."); + } + + pino = sbuf.st_ino; + pdev = sbuf.st_dev; + for (;;) { if (stat("..", &sbuf) < 0) { chdir(buf0); noholdintr(); return ztrdup("."); } ! ! ino = pino; ! dev = pdev; ! pino = sbuf.st_ino; ! pdev = sbuf.st_dev; ! ! if ((ino == pino && dev == pdev) || (ino == rootino && dev == rootdev)) { chdir(buf0); noholdintr(); *************** *** 160,194 **** (fn[1] == '\0' || (fn[1] == '.' && fn[2] == '\0'))) continue; ! if ((ino_t) de->d_ino == ino) { lstat(fn, &sbuf); ! if (sbuf.st_dev == dev) ! goto match; } } closedir(dir); ! dir = opendir("."); ! while ((de = readdir(dir))) { ! char *fn = de->d_name; ! /* Ignore `.' and `..'. */ ! if (fn[0] == '.' && ! (fn[1] == '\0' || ! (fn[1] == '.' && fn[2] == '\0'))) ! continue; ! lstat(fn, &sbuf); ! if (sbuf.st_dev == dev) ! goto match; } - noholdintr(); - closedir(dir); - return ztrdup("."); - match: - strcpy(buf3, de->d_name); if (*buf2) strcat(buf3, "/"); strcat(buf3, buf2); strcpy(buf2, buf3); - closedir(dir); } } --- 167,189 ---- (fn[1] == '\0' || (fn[1] == '.' && fn[2] == '\0'))) continue; ! if (dev != pdev || (ino_t) de->d_ino == ino) { lstat(fn, &sbuf); ! if (sbuf.st_dev == dev && sbuf.st_ino == ino) { ! strcpy(buf3, de->d_name); ! break; ! } } } closedir(dir); ! if (!de) { ! noholdintr(); ! return ztrdup("."); } if (*buf2) strcat(buf3, "/"); strcat(buf3, buf2); strcpy(buf2, buf3); } } ^ permalink raw reply [flat|nested] 19+ messages in thread
* zsh-3.0.4 blessed patches (was Re: zgetcwd patch?) 1997-08-25 5:06 ` Zoltan Hidvegi @ 1997-08-25 17:06 ` Mark Borges 1997-08-25 17:46 ` Zoltan T. Hidvegi 0 siblings, 1 reply; 19+ messages in thread From: Mark Borges @ 1997-08-25 17:06 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: Zsh hacking and development >> On Mon, 25 Aug 1997 01:06:54 -0400 (EDT), >> Zoltan Hidvegi(ZH) wrote: [...] ZH> Sorry for my silence about this. Zsh-3.1.1 already had a fix for ZH> this promlem, here is the patch for zsh-3.0.4. It avoids the ZH> double scan you noticed. I'm running the stock zsh-3.0.4. I've noticed there have been a few patches since it's been released, and I lost track of which ones are "must haves". Can someone (Zoltan?) suggest a list of "blessed" patches? Alternatively, are there plans for a 3.0.5 release (I'm not ready to install 3.1.1 here yet). Thanks. -- -mb- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: zsh-3.0.4 blessed patches (was Re: zgetcwd patch?) 1997-08-25 17:06 ` zsh-3.0.4 blessed patches (was Re: zgetcwd patch?) Mark Borges @ 1997-08-25 17:46 ` Zoltan T. Hidvegi 1997-08-25 21:35 ` Geoff Wing 0 siblings, 1 reply; 19+ messages in thread From: Zoltan T. Hidvegi @ 1997-08-25 17:46 UTC (permalink / raw) To: Mark Borges; +Cc: hzoli, zsh-workers Mark Borges wrote: > patches? Alternatively, are there plans for a 3.0.5 release (I'm not > ready to install 3.1.1 here yet). Yes, there will be a zsh-3.0.5 release. Zoltan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: zsh-3.0.4 blessed patches (was Re: zgetcwd patch?) 1997-08-25 17:46 ` Zoltan T. Hidvegi @ 1997-08-25 21:35 ` Geoff Wing 1997-08-25 22:08 ` Zoltan Hidvegi 0 siblings, 1 reply; 19+ messages in thread From: Geoff Wing @ 1997-08-25 21:35 UTC (permalink / raw) To: zsh-workers hzoli@VNET.IBM.COM <hzoli@VNET.IBM.COM> typed: :Mark Borges wrote: :> patches? Alternatively, are there plans for a 3.0.5 release (I'm not :> ready to install 3.1.1 here yet). :Yes, there will be a zsh-3.0.5 release. Any timeline on that? I just got half way through sending in another bug report last night til I remembered seeing something similar and grep'd through the list for it. Lucky I keep all the old messages :-) -- Geoff Wing [mason@primenet.com.au] Phone : +61-3-9818 2977 Technical Manager: PrimeNet Computer Consultants Facsimile: +61-3-9768 2909 Web: <URL:http://www.primenet.com.au/> Mobile : 0412 162 441 [ Boulderdash: <URL:http://ciips.ee.uwa.edu.au/~williams/bd/> ] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: zsh-3.0.4 blessed patches (was Re: zgetcwd patch?) 1997-08-25 21:35 ` Geoff Wing @ 1997-08-25 22:08 ` Zoltan Hidvegi 0 siblings, 0 replies; 19+ messages in thread From: Zoltan Hidvegi @ 1997-08-25 22:08 UTC (permalink / raw) To: mason; +Cc: zsh-workers > :Yes, there will be a zsh-3.0.5 release. > > Any timeline on that? I just got half way through sending in another bug > report last night til I remembered seeing something similar and grep'd through > the list for it. Lucky I keep all the old messages :-) I hope this week. The (ab#)# glob bug will probably not be fixed in the 3.0 series, since I suspect that this will require a lot of changes in the glob code. Zoltan ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~1997-08-26 0:40 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-08-08 20:51 weird zsh startup behavior John M. Harres 1997-08-09 1:16 ` Zoltan Hidvegi 1997-08-09 4:39 ` John M. Harres 1997-08-09 5:11 ` Geoff Wing 1997-08-09 5:58 ` John M. Harres 1997-08-10 7:30 ` Todd Larason 1997-08-12 15:31 ` John M. Harres 1997-08-12 16:04 ` Todd Larason 1997-08-12 16:15 ` John M. Harres 1997-08-15 13:15 ` zgetcwd patch? John M. Harres 1997-08-18 5:05 ` Bart Schaefer 1997-08-18 16:28 ` John M. Harres 1997-08-18 19:48 ` Todd Larason 1997-08-19 9:31 ` Bart Schaefer 1997-08-25 5:06 ` Zoltan Hidvegi 1997-08-25 17:06 ` zsh-3.0.4 blessed patches (was Re: zgetcwd patch?) Mark Borges 1997-08-25 17:46 ` Zoltan T. Hidvegi 1997-08-25 21:35 ` Geoff Wing 1997-08-25 22:08 ` Zoltan Hidvegi
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).