Read and Write Sector

  • Thread starter Thread starter Sumana
  • Start date Start date
S

Sumana

Hi All,
We developed our project on VC++.Net console application to
create image of disk and to write the image
We are having problem with reading and writing the sector
beyond 6GB Disk or Partition
we are using ReadFile , WriteFile and setFilePointerEx to read
and write the sectors and we are reading/writing 102400 sectors together,
even we have reduced the sectors still it is not able to
read or write,
our program is working fine with disk or partition below 6GB
with no data loss.
We are not able track out what the problem is, can anyone
tell what problem is.?
 
Could you give us some more information / source code?
what method are you using to read and write sectors using the file IO
routines?

without more information, my best guess is that you are using
FILE_FLAG_NO_BUFFERING, and the buffer length or offset is not a multiple of
the volume sector size, or that your buffer is not sector aligned.

tht would be consistent with your observation that it doesn't work with
volumes > 6G, since they are likely to have other sector sizes than small
volumes.

kind regards,
Bruno.
 
and how do you know that sector size is 512? doesn't that depend on the
volume size? in that case it could be 1024, and that could make your offsets
or sizes invalid, since they have to be a multiple of the real sector size.

kind regards,
Bruno.
 
Hi

we are using this code to create the handle
//device name can be physical disk or drive

hDevice = CreateFile(_devicename,

GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE,

NULL, OPEN_EXISTING, 0, NULL);

//we set the pointer usinf this code which point to the specfied sector

// we had used SetFilePointer but it was not able to perform operation
beyond 5 GB so we used SetFilePointerEx



LARGE_INTEGER L,L1;

L.QuadPart =(startinglogicalsector*512);

if(SetFilePointerEx (hDevice, L,&L1, FILE_BEGIN)== INVALID_SET_FILE_POINTER)

return NULL;



// To read the sector information we are using ReadFile

// buffer size is 512 * 102400 bytes

// number of sectors = 102400 sectors



ReadFile (hDevice, buffer, 512*numberofsectors, &bytesread, NULL);

if(bytesread == 0)

return NULL;

this function is reading 52428800 bytes and writes into the file as image
file



///// for writing into the sectors

// we are opening the image file read the 5242880 bytes and writes into the
sectors



LARGE_INTEGER L,L1;

L.QuadPart =(startinglogicalsector*512);

if(SetFilePointerEx (hDevice, L,&L1, FILE_BEGIN)== INVALID_SET_FILE_POINTER)

return NULL;

if (!WriteFile (hDevice, buffer, 512*numberofsectors,&byteswrite, NULL))

return false;

Thanks
 
if the sector size is really 1024, and you try to read an un-even times 512
bytes, the resulting size is not a multiple of 1024.
the same is true for the offset. if your starting offset is not a multiple
of 1024, the file operation may fail.

if you cannot get the real sector size from the HDD parameters, the best
solution would be to use a multiple of 4096 bytes. that way your sizes and
offsets will always be a multiple of 512, 1024, 2048 and 4096.
whatever size you use, you should always make it a constant. using numbers
like 512 directly in your code can lead to errors if you ever need to change
them.

I think you should at least try this to make sure that that is not the
problem. this is not a difficult test to do.

If that does not solve your problem, you might want to post this question to
development.device.drivers
another good place would be the NTDEV and NTFSD list on www.osronline.com. i
know that there are a lot of file system experts active on those forums.

kind regards,
Bruno.
 
Hi

it is working fine till 6 GB disk or drive and we have got sample program to
check the information in each sector of the drive in HEX form or in
character form.
we have got lot of document which specifies that basic allocation unit of
each drive or disk is 512 bytes, even while formatting the disk we are
allocationing the unit with the multiply of 512 like 1024, 2048, 4096 , we
don't think it may create any problem

most of the problem occurs when we restarts the system , after performing
write operation in the sector

Windows XP displays the below information before it loads the OS

//////////////////////////////////////////////////////////////////////////////////
One of your disks needs to be checked for consistency. You
may cancel the disk check, but it is strongly recommended
that you continue.
Windows will now check the disk.
The file name index present bit in file 0x5 should not be set.
Correcting a minor error in file 5.
The file name index present bit in file 0xb should not be set.
Correcting a minor error in file 11.
Index entry _restore{15280B1B-8B59-4C06-8331-AC6937D07FFC} of index $I30 in
file 0x21 points to unused file 0x19.
Deleting index entry _restore{15280B1B-8B59-4C06-8331-AC6937D07FFC} in index
$I30 of file 33.
Index entry _RESTO~1 of index $I30 in file 0x21 points to unused file 0x19.
Deleting index entry _RESTO~1 in index $I30 of file 33.
Cleaning up minor inconsistencies on the drive..................etc

Windows has made corrections to the file system.

9213277 KB total disk space.
84 KB in 4 files.
8 KB in 10 indexes.
0 KB in bad sectors.
49149 KB in use by the system. //////// By this it is clear
that system is using this much number of Sector
48128 KB occupied by the log file./////// this sectors are locked by
the OsS
9164036 KB available on disk.

4096 bytes in each allocation unit.
2303319 total allocation units on disk.
2291009 allocation units available on disk.



//////////////////////////////////////////////////////////////////////////////////////////////

may be the OS have some control over some sectors?
 
Back
Top