jonheal;184343 Wrote: > I can see how it might be possible for the OS to query the volume > directory about a file, and then get a response, "Yes, we have that > file. This portion of it is on sector X of the hard drive, and that > portion of it is on sector Y ...," etc. And then with some > intelligence, SlimServer looks into the first and last portions of the > file that the directory points to for tag information.
The application has no idea what sectors the file occupies, nor does it care. That is the OS's problem. The OS just says, "Okay, found it, you have permissions to read it as you asked, and next time you want to do something tell me you want to fondle file-handle-5 for your process" The application program calls read( 5, buffer, length)... the OS looks up the '5' in its table for the process, finds the file handle, figures out what the current read-pointer is, figures out what blocks are needed to be read in if any (it may be in buffers), and does so, copying length bytes to the buffer, and returning. > > But, if the OS must open the file, then it would need to read all of > the files bytes and load them into memory -- and bring them across the > network to do so. No, it wouldn't. > > If you select a file's properties in Windows, you see name, last > modifed, size, etc. and regardless of selecting a big or small file, > that dialog appears instantly. My guess is that this information is not > coming from the file in real time, but was added to the disk's directory > when the file was last modified. That isnt coming from the file at all: it is coming from the directory. The directory points to the file and has all the information about it. (Or something, I haven't seriously played with Windows file systems). On Unix it is a bit more obtuse: the directory contains a list of filenames, and inode numbers... the inode numbers contain all the information about a file (permissions, ownership, blocks used, etc), but same basic concept. Just the real details about a file arent in the directory itself. (This is, btw, how "hard links" work on Unix ... two directory entries pointing to the same inode, which points to the same file.) > > To me, the SMB_COM_READ command looks like it is reading a portion of a > file already in memory. There's nothing in the parameters about disk > sectors. No, it reads it from the disk. Modern OS's don't need to read stuff into memory on open. Even CP/M-80 didn't. -- snarlydwarf ------------------------------------------------------------------------ snarlydwarf's Profile: http://forums.slimdevices.com/member.php?userid=1179 View this thread: http://forums.slimdevices.com/showthread.php?t=33041 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
