On 15 Apr 99, at 19:35, Joan Rapier wrote:

> I'm really not getting this.  When I set up a multi-boot machine for my
> former employer, my boss wanted NT, '95 and '98 on his system.  I built it
> up from scratch - quite a learning process but that's another story.
>   Anyway, what I discovered was I could not "see" a FAT32 partition from
> w/in a NTFS partition.  I configured two machines peer-to-peer in that
> office.  The other machine was strictly NT Workstation using NTFS.  For
> them to share their data, I had to put the data on a FAT16 partition so the
> two users could "see" the data no matter what partition they were in at the
> time.
>
> I found I literally could not "see" a FAT32 partition ("drive") if I was
> booted into NT.  I know I'm missing something here.  Can someone explain to
> me why I saw this?

  When you say "w/in a NTFS partition", the important thing is that they had
booted into NT, which has no FAT32 support.  To NT looking at the disk, FAT32
is "some foreign partition/volume that I don't know how to read".  [Win 9x,
without third-party help, views NTFS similarly.  You effectively must use FAT16
only if you want all data accessible on a multi-boot machine.]

> The same issue came up in my Networking Essentials class the other night
> and I left there still not understanding why I am being told it doesn't
> matter what file system the computers are using in the face of my having
> experienced what seems to be contrary to that.

  When the drive is on some other machine, across a network, your local OS
doesn't talk directly to the drive.  It asks the OS *on the machine where the
drive is* to talk to it.  It becomes that OS's responsibility to translate
requests for folders and files down to clusters/nodes and finally sectors on
the drive, and so the requesting station is insulated from those details.
  Basically, an application running locally requests something from the OS by
drive/path (or UNC name).  A networking component called the "redirector",
inside the OS file-handling code, recognizes that this is a remote request
and forwards it to the remote machine before the client OS gets down to
details of drive formatting.
  So to an application (and, most of the time, to a user) a remote volume
looks just like a local one.  But that's at an abstract level of named files
and paths, and there's no local resolution of it down to clusters and sectors.

  The key is the network.  The OS on the host which owns the volume doesn't
have to be the same as the OS on the client machine that is requesting the
files.  On a multi-boot config, you only have one OS running at a time, so
there's no opportunity for the client to rely on some other OS's support for
a different partition format.
  Your experience is correct; the explanations you've seen on this list are
correct.  They're applying to fundamentally different configurations, which
is why they are able to come to different conclusions.


David G

                Curious about the people moderating your
                   messages? Visit our staff web site:
                     http://nospin.com/pc/staff.html