469,610 Members | 1,761 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,610 developers. It's quick & easy.

Can 98SE read files from NTFS Drives?

I have been told by a local PC club technician that 98SE cannot read NTFS
drives in a network. Is this true? TIA, Jim.
Jul 23 '05 #1
2 3012
"Jim Richards" wrote:
I have been told by a local PC club technician that 98SE cannot read
NTFS drives in a network. Is this true? TIA, Jim.

In addition to the excellent thread linked to in another message, please
allow me to clarify the situation.

Forgive me if you know all this, but perhaps someone else reading this
thread in the future won't. Also, lest this be seen as OT, I think there
are plenty of people that end up in situations managing SQL Server even
though they've never been trained on things like hardware and OS
operations... So, to make a long story, er, less long:

All (modern) OS's use layers of abstraction. A Windows computer has a
driver to talk to the physical disk drive via the bus it's connected to
(SCSI, ATA/IDE, SATA, etc). A file system driver sits "on top" of that to
organize the disk into a logical view. Without the file system driver, you
have to access the disk by "block": I've seen mainframe programs based
around this and *trust* me, it's ugly :) FAT32, NTFS, ext3, ReiserFS, et al
are file systems that allow you to view a physical disk as directories and
files. Without them, you couldn't load the system library
c:\windows\system32\user32.dll... You'd need to know to read blocks 345-392
to get that DLL (and that's vastly oversimplified).

This often confuses people because Windows allows you to map a drive to a
network share. However, that mapped drive is *not* sending commands
directly to the disk device on the server. The mapped drive is presented by
a driver that talks to the server over a network instead of directly to a
physical drive. Not only is this far better, but it's really the only
option... Can you imagine 100 client computers all trying to physically move
the drive heads around on your server?

Another way to think of it is that network file servers work like SQL
Server: you send a request and you get a response. You don't really care if
the server read your file from a single IDE drive formatted with FAT32, a
7TB RAID 1+0 disk array formatted with NTFS 5, or from a special interface
to thousands of trained orangutans with legal pads (which is how we run our
servers at my company ;).

The problem with Win9x is that there's no NTFS file system driver available
from Microsoft (although it wouldn't surprise me if someone on the Internet
had hacked one together). So Win9x can't talk to a physical drive formatted
with NTFS. But this doesn't matter on the network because the server is in
charge of the NTFS drive.

So, the PC tech is completely wrong. But...

There's a protocol known as iSCSI that allows you send SCSI bus commands
over TCP/IP. It allows you to use a network as the bus to a drive array.
If for some bizarre reason you managed to get a hold of an iSCSI driver for
a Windows 98 computer so that you could access a networked drive array,
you'd need a FAT16 or FAT32 partition on the array since the Win98 computer
would be sending physical commands to the array. But... that's mostly
theoretical: I can't imagine that happening unless your were a masochist,
had tons of cash, and then got drunk and decided to hire some systems
programmers to put together incredibly bizarre systems :)

Jul 23 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Chris | last post: by
reply views Thread by DEATH TO KENT WEST HILL | last post: by
6 posts views Thread by Rolf Schroedter | last post: by
4 posts views Thread by igg | last post: by
2 posts views Thread by Phil Hey | last post: by
4 posts views Thread by jabslim via DotNetMonster.com | last post: by
reply views Thread by devrayhaan | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.