is it safe to assume hard disk sector size is 512 bytes for Windows/DOS machines or is there a way to determine sector size on local machine?
is it safe to assume hard disk sector size is 512 bytes for Windows/DOS machines or is there a way to determine sector size on local machine?
why do you even need it?
Away.
Not truly safe to assume; what is the application that you need that info for? There should be some WinAPI commands...
Use GetDiskFreeSpace or GetDiskFreeSpaceEx. GetDiskFreeSpace returns pointers to the information.
edit:
to clarify, the parameterlist:
Or look hereCode:BOOL GetDiskFreeSpace( LPCTSTR lpRootPathName, LPDWORD lpSectorsPerCluster, LPDWORD lpBytesPerSector, LPDWORD lpNumberOfFreeClusters, LPDWORD lpTotalNumberOfClusters );
Last edited by darksaidin; 07-25-2003 at 03:16 PM.
The programs I've written so far can be handled in one file, although sometimes I'll break them up into different header files, etc. However, the driver program is all in one file. If the program requires a data file, there was always enough room to read the entire file into RAM. But what if I want to create a bigger program or use a bigger data file? Say I wanted to create an online telephone book for the city where I live (yes, I know the project has already been done). If there were a million entries (or more) then not all the entries could be read into RAM. How would I work this out. I searched the net about database file management and learned found they often use B-trees, so I read up on them. B-trees use nodes that contain muliple items and multiple pointers to other nodes. To optimize things each node is often manipulated to be of a size that is as close to but less than the size of a sector. That way the hardware can locate the correct address "faster" for each read/write action and each read/write action can be done one sector at a time using read() and write() stream methods to read/write one node, that is one object at a time. Therefore, if I decide to go ahead and try to implement a B-tree to see if I can do such a "large scale" project it seems prudent to see if sectors contain come in a standard size or if there is a standard, or a non-standard, way to determine the size of a a sector (yes, I know I can write the tree and use it appropriately without the sector size/node size optimization, but what they hey, if I'm going to spend the time to do it, I might as well check it out as far as I can, right?). I found some information that said sectors for Windows/DOS file formats can range from 64 to 4096 bytes and other information that said that all Windows/DOS hard drive and floppy disk sectors are de facto 512 bytes and all Windows formatted CD-ROMs are de facto 2048 bytes per sector (interesting trivia if I do nothing else with this project). So I thought I'd ask whether it was safe to assume that it's 512 bytes per sector or whether it's something that should be checked somehow. That's all.
Thanks darksaidin. I found one reference to that function in my reading, but your use of it was clearer than the reference I found (I assume the function is in windows.h?). I'll check out your link next.
Your information is incorrect. Although most sectors today are 512 bytes there is not a set standard. All of my DOS manuals specifically tell the programmer to get the sector size via and interrupt call (or via a WinAPI call in Windows) because there is a slight chance that the sector size is not 512 bytes. But you do not need this information unless you are writing your own low-level disk i/o functions, part of an OS kernel, a low-level disk utility program, etc....found some information that said sectors for Windows/DOS file formats can range from 64 to 4096 bytes and other information that said that all Windows/DOS hard drive and floppy disk sectors are de facto 512 bytes and all Windows formatted CD-ROMs are de facto 2048 bytes per sector (interesting trivia if I do nothing else with this project).
Be very careful when messing with sectors because the OS does not protect against incorrect sector size calculations nor does it protect against incorrect LBA translations. It is very possible that you could destroy and/or truncate the FAT cluster/chain if you do this incorrectly. As for NTFS, there isn't a lot of information about it yet on the internet so I wouldn't touch it.
Remember that in FAT each cluster is going to point to the next cluster in the chain until FFFFh is reached (in FAT32) or EOF. If it does not then the cluster chain will end prematurely and your file will load incorrectly into memory.
Again - be very very careful when messing with the FAT. If you do not know what you are doing it is best to leave it be.
