thunder44
asked on
Write to a Specific Disk Location
Hi,
Is there any way to write/save a file to a specific portion of a hard or floppy disk using VB5?.
I see MS Scandisk (for DOS) showing disk areas filled by data and others empty. So I assume that there must be a way to build up a picture of the disk sectors themselves, and if thats so, perhaps dump a file to a specific empty disk space. I wonder if anyones ever heard of any way of doing this. Any leads to stuff on the net that might help would be appreciated.
chevy75@mindspring.com
Is there any way to write/save a file to a specific portion of a hard or floppy disk using VB5?.
I see MS Scandisk (for DOS) showing disk areas filled by data and others empty. So I assume that there must be a way to build up a picture of the disk sectors themselves, and if thats so, perhaps dump a file to a specific empty disk space. I wonder if anyones ever heard of any way of doing this. Any leads to stuff on the net that might help would be appreciated.
chevy75@mindspring.com
Windows / DOS uses a forward seeking File Allocation method. What that means is that when a disk write operation is issued.. the operating system goes through the file allocation table sequentially, and starts writing the file in the first open space it encounters. If the file is longer than the free sector, the operating system continues along the file allocation table, and uses the next available sector. When you delete a file, the file allocation sectors that were used by it are freed up.
As the free sectors and sectors that need to be written don't always match up, you get what is called file fragmentation.. where parts of a given file could be all over the disk.. and yes.. with a high level of file fragmentation.. reading a file can be an all over the disk retrieval chore. That is why MS provides a Disk Defragmenting utility, which when run, pieces your files back together all in one contiguous space.. and I suggest you run it routinely.
As the File Allocation table is a very low level operating system function.. (if it gets screwed up.. you lose your whole disk).. it is definitely NOT a good idea to mess with it.
In all honesty, if you defrag your disk routinely, then having a little bit of fragmentation (<5%) is no real big problem.. you won't even notice it.. <smile>.
As the free sectors and sectors that need to be written don't always match up, you get what is called file fragmentation.. where parts of a given file could be all over the disk.. and yes.. with a high level of file fragmentation.. reading a file can be an all over the disk retrieval chore. That is why MS provides a Disk Defragmenting utility, which when run, pieces your files back together all in one contiguous space.. and I suggest you run it routinely.
As the File Allocation table is a very low level operating system function.. (if it gets screwed up.. you lose your whole disk).. it is definitely NOT a good idea to mess with it.
In all honesty, if you defrag your disk routinely, then having a little bit of fragmentation (<5%) is no real big problem.. you won't even notice it.. <smile>.
wsh2's comments do NOT apply to NTFS disks that use a whole 'nother approach.
M
M
Mark2150's comment about NTFS should be taken in good stead.. <smile>.
As Mark2150 is an expert on NTFS, perhaps he could elaborate on this whole 'nother approach' concept. As NTFS is a VERY mature technology (ie.. been around for quite a bit), I tend to believe that NTFS shares many of the same traits as its Windows / DOS counterparts. The only difference being.. it is wrapped up in phenomenal security.. combined with perpetual disk housekeeping tasks being performed routinely.
As Mark2150 is an expert on NTFS, perhaps he could elaborate on this whole 'nother approach' concept. As NTFS is a VERY mature technology (ie.. been around for quite a bit), I tend to believe that NTFS shares many of the same traits as its Windows / DOS counterparts. The only difference being.. it is wrapped up in phenomenal security.. combined with perpetual disk housekeeping tasks being performed routinely.
wsh2: NTFS is *not* just FAT with security. An NTFS drive doesn't have a single monolithic FAT, and the format of the directories is also different--in fact, it's possible for a small file to be completely contained within its directory entry under NTFS! In addition, an NTFS file is formed of one or more "streams", one of which is named (the one you actually see) and the others accessible programmatically. I could go into a *lot* more detail if I could find the relevant MSDN article on this...
wsh2: Found it! Try looking at Knowledge Base article Q100108 for a concise description of FAT, HPFS and NTFS. This is fairly old (it refers to NT 3.1) but it gives a good idea of the differences.
Didn't say I was expert on NTFS. Said that FAT's don't apply - which is 100% correct. NTFS is sufficiently differnt that all existing disk tools have to be rewritten to support. Entire paradigm of storage allocation is radically different. Since NT was designed to eliminate DOS there are no "DOS Calls" to handle it. All old .ASM that does direct disk I/O will *NOT* run.
M
M
ASKER
Thanks for the input so far, just as a point of reference, any attempt to mess with the FAT would obviously be done on a disk carrying nothing valuable in the first place. This whole idea is an experiment out of curiosity, not necessity. The initial victim would probably be a floppy.
I obviously need to research more on the FAT and using BIOS calls even if that means retreating from VB5 into some DOS level language like C, vaugely remember someone doing BIOS calls in this and QB45 but I may be mistaken.
Judging by the comments above there doesn't seem to be a pre-cut solution anyones heard of, but mark2150's comments come closest to a place to start (should have thought of BIOS calls myself), so I'll take it from there. Post an answer not a comment mark2150 and collect your points. Thanks to all.
I obviously need to research more on the FAT and using BIOS calls even if that means retreating from VB5 into some DOS level language like C, vaugely remember someone doing BIOS calls in this and QB45 but I may be mistaken.
Judging by the comments above there doesn't seem to be a pre-cut solution anyones heard of, but mark2150's comments come closest to a place to start (should have thought of BIOS calls myself), so I'll take it from there. Post an answer not a comment mark2150 and collect your points. Thanks to all.
Congrats Mark2150.. <smile>.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks to all
My Que "DOS Programmers Reference" (ISBN 0-88022-327-8) says that you should be using BIOS INT13H, function 03H, "Write Disk Sector".
Calling registers:
AH = 03H
AL = Number of sectors (128 byte) to transfer (1-9)
ES:BX = Pointer to data buffer
CH = Track
CL = Sector
DH = Head (0-1)
DL = Drive (0-3)
Have FUN! :-)
M
Calling registers:
AH = 03H
AL = Number of sectors (128 byte) to transfer (1-9)
ES:BX = Pointer to data buffer
CH = Track
CL = Sector
DH = Head (0-1)
DL = Drive (0-3)
Have FUN! :-)
M
You can get the contents of the disk by looking at the FAT (but not under NT). The FAT contains the pointer to the first cluster of the file chain and you *could* theoretically write a file block by block, but VB has no provision to do so as this is not a function that application level code should be performing.
There are internal hooks for this stuff because SCANDISK and DEFRAG can do it, but they weren't written in VB. I can do it in DOS using BIOS calls, but the need has never arisen at the VB level.
M