No NFS involved. It's all on the same system, albeit not a simple one! :-)
It's my work laptop, I'll describe the config below (to avoid confusing the
issues here). I had to shut it down, so I'm working from memory on some
details.
If I can get it into the same state again I'll try the ls -li comparision
going
up the tree. My suspicion is that I can predict the results (it will show
the inodes on a different file sys - see discussion below).
I did try most of what Ben suggested. Here's a summary, with some of
the history that led to this curious occurance: (note, file names and
trees
are renamed for brevity)
There are two copies of the file (let's call it "script" for brevity) on
the
system, in /build/bl1/cut/script and in /mnt/shared/cut/script. I'm
working in RH6.2 using gnome, with three or four windows open.
In the edit window I had previously (a long time ago, maybe an hour)
cd'ed to /mnt/shared/cut and browsed around. Then I cd'ed to
/build/bl1/cut and started trying to get the version there working with
this baselevel. That was perhaps fifteen to thirty minutes earlier. At
some point I noticed that edits made in a different window that was
also set to /build/bl1/cut were not being seen in the first window. That
led to the test I described.
THIS=`pwd`
diff script $THIS/script # gets a list of differences
diff ./script $THIS/script # gets the same list of differences
pwd # displays /build/bl1/cut
echo $THIS # displays /build/bl1/cut
more $THIS/script # as I recall shows the contents of
/build/bl1/cut/script
more script # as I recall shows the contents of
/mnt/shared/cut/script
ls # as I recall shows
/mnt/shared/cut file timestamps size etc
ls $THIS # as I recall shows /build/bl1/cut
NOTES:
- I may have used grep instead of more, and inferred versions (tree locs)
from the results. I do distinctly remember that ls showed a different
directory than did another ls in a different window also set to the same
directory. I did check that the pwd display in both windows was the same.
- the two directories are on different file systems, and the file systems
are of different types. I don't think this should be significant but it
might be. I do suspect that the sequence of cd's might also be
significant.
- I have previously had some very erratic test results over the past
several days that suggest that there is some stale cache or file context
that doesn't always get flushed. That's why I tried to use "sync" to
ensure that I would see the edit changes.
FWIW, here's the details about the disk layout, it's a multi-boot setup
using System Commander 2000 to manage a 24gb disk.
Partition 0 - C: 2gb FAT32 Windoze 98
Partition 1 - unused 4gb (shows as Linux Swap, is really reserved for
Solaris)
Partition 2 - Extended 14gb
Logical 1 - Linux 2gb mounts as "/"
Logical 2 - Linux swap 500mb
Logical 3 - D: 4gb FAT32 Windoze 2K
Logical 4 - E: 7gb FAT32 "shared"
Partition 3 - unused 4gb (reserved for FreeBSD)
In addition to / Linux mounts
C: on /mnt/win98
D: on /mnt/win2k
E: on /mnt/share
Incidentally, there is a bit of a glitch in SysCmdr, I suspect it has to do
with the slight-of-hand involved in manipulating the boot blocks with the
ExtPar. The symptom is that when I've had Win98 booted and then exit, the
next attempt to boot into Linux fails - when I ctl-alt-del to force a POST
reboot the next (and all subsequent) attempt to boot into Linux work ok,
until the next time Win98 is booted. I forget whether the same behavior is
caused by Win2K (I don't boot it very often!) but I seem to recall that it
doesn't. Anyway, that's a side issue, I don't think any of this should be
germane to the problem of the misdirected disk retrievals (but I could be
wrong).
Any insights are gratefully welcomed. THANKS!
--Bruce McCulley
Derek Martin wrote:
> On Fri, 4 Aug 2000, Benjamin Scott wrote:
>
> >
> > You are right, this calls for sanity checks. For example, do ...
> >
> > pwd
> > echo $THIS
> > ls -l release.script $THIS/release.script
>
> even better, do ls -li and compare the inode numbers.
>
> Is this on an NFS mount by any chance? One of our web gurus asked me
> about a very similar situation about a week ago, which to be honest I'd
> completely forgotten about until last week (sorry Niall).
>
> --
> Derek Martin
> System Administrator
> Mission Critical Linux
> [EMAIL PROTECTED]
>
> **********************************************************
> To unsubscribe from this list, send mail to
> [EMAIL PROTECTED] with the following text in the
> *body* (*not* the subject line) of the letter:
> unsubscribe gnhlug
> **********************************************************
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
