How to Verify a file on a USB Thumb Drive?

mike · Joined: 19 Jan 2008 Posts: 29

How to Verify a file on a USB Thumb Drive?

I'd to write some files to a USB thumb drive and verify
that they were written correctly.

Reading the file back is useless, because you get what's in
the file cache and not what's on the drive.

I find lots of info on flushing WRITE buffers, but nothing
about invalidating the READ buffers.

Dismounting/remounting by using the safe removal tool and
unplugging/plugging the device does the job, but it's messy.
Can this be done programatically?

I found a utility that changes the drive letter on the fly.
Figured that'd do it.
But it still gives you back the old cached file contents
when you read from the new drive letter.

I'm currently calling chkdsk. It dismounts, checks, then
remounts the USB drive. That works on the test system,
but I expect is fraught with issues in the real world.
And it's slow on a big flash drive with lots of files.

Environment is Windows 2k/xp, but I'd like it to work on 98SE too,
where there's no chkdsk.
I have no idea what might be the Flash file system on a random
flash drive, fat/fat32/ntfs/???

VB6 is the development tool.

Suggestions?
Thanks, mike

--
Return address is VALID!

Archived from group: microsoft>public>vb>winapi

Thorsten Albers · Joined: 04 Oct 2007 Posts: 756

mike schrieb im Beitrag
...
> I'd to write some files to a USB thumb drive and verify
> that they were written correctly.
> Reading the file back is useless, because you get what's in
> the file cache and not what's on the drive.

Use CreateFile() with FILE_FLAG_NO_BUFFERING. But read the documentation
carefully.
And remember: Even if it is possible to turn of the Windows file caching,
there still may be a hardware caching of the storage device.

> Environment is Windows 2k/xp, but I'd like it to work on 98SE too,
> where there's no chkdsk.

Of course chkdsk is available on Windows 98 SE (it already was available on
MS DOS 3!).

--
----------------------------------------------------------------------
THORSTEN ALBERS Universität Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------

mike · Joined: 19 Jan 2008 Posts: 29

Thorsten Albers wrote:
> mike schrieb im Beitrag
> ...
>> I'd to write some files to a USB thumb drive and verify
>> that they were written correctly.
>> Reading the file back is useless, because you get what's in
>> the file cache and not what's on the drive.
>
> Use CreateFile() with FILE_FLAG_NO_BUFFERING. But read the documentation
> carefully.
> And remember: Even if it is possible to turn of the Windows file caching,
> there still may be a hardware caching of the storage device.

Thanks, I was hoping to avoid all the sector alignment stuff.
Simple stuff like this:

If you have a situation where you want to flush all open files on the
current logical drive, this can be done by:

hFile = CreateFile("\\\\.\\c:", ....);
FlushFileBuffers(hFile);

apparently only works on writes.
>
>> Environment is Windows 2k/xp, but I'd like it to work on 98SE too,
>> where there's no chkdsk.
>
> Of course chkdsk is available on Windows 98 SE (it already was available on
> MS DOS 3!).
All I get is a message telling me to run scandisk. On win2k/xp
it forces an unmount then remounts the drive...flushing the READ cache.
Maybe I need to add some command-line parameters for 98?

Thanks, mike
>

--
Return address is VALID!

Thorsten Albers · Joined: 04 Oct 2007 Posts: 756

mike schrieb im Beitrag ...
> Thanks, I was hoping to avoid all the sector alignment stuff.
> If you have a situation where you want to flush all open files on the
> current logical drive, this can be done by:
> hFile = CreateFile("\\\\.\\c:", ....);
> FlushFileBuffers(hFile);
> apparently only works on writes.

What do you mean by "only works on writes"? For a file opened for both
reading and writing the read and write buffers are the same, and
FlushFileBuffers() will do anything needed.
But for what you want to do FlushFileBuffers() is not sufficient since this
empties the file >>read/write buffers<< only! It doesn't tell the system to
flash the system's >>file caching buffers<<.

> > Of course chkdsk is available on Windows 98 SE (it already was
available on
> > MS DOS 3!).
> All I get is a message telling me to run scandisk. On win2k/xp
> it forces an unmount then remounts the drive...flushing the READ cache.
> Maybe I need to add some command-line parameters for 98?

Post the code which calls chkdsk. But of course it is not unlikely that
chkdsk behaves other on a Win 9x system.

--
----------------------------------------------------------------------
THORSTEN ALBERS Universität Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------

mike · Joined: 19 Jan 2008 Posts: 29

Thorsten Albers wrote:
> mike schrieb im Beitrag ...
>> Thanks, I was hoping to avoid all the sector alignment stuff.
>> If you have a situation where you want to flush all open files on the
>> current logical drive, this can be done by:
>> hFile = CreateFile("\\\\.\\c:", ....);
>> FlushFileBuffers(hFile);
>> apparently only works on writes.
>
> What do you mean by "only works on writes"? For a file opened for both
> reading and writing the read and write buffers are the same, and
> FlushFileBuffers() will do anything needed.
> But for what you want to do FlushFileBuffers() is not sufficient since this
> empties the file >>read/write buffers<< only! It doesn't tell the system to
> flash the system's >>file caching buffers<<.

I'd rather not argue about the terms. What I want to do is guarantee
that I read directly from the flash drive hardware the FIRST time I open
the file.
I'm only gonna read the file once to verify its contents. I don't care
if it's cached again.

That's why I'm thinking cache flush and not unbuffered reads.

The desired process is this:
1)Write somefiles to the flash drive.
2)Do some operation that forces the FIRST read of a file to be directly
from the hardware.
3)Read/verify the contents of files written in step 1 ONCE.

You tell me what terms I should use to describe it.

Chkdsk appears to have a side effect of unmounting/remounting the
flash drive to accomplish the desired result for step 2.

I was hoping to find a (simple) way to do it directly without relying on
a side
effect of a utility that seems to behave differently in different
windows OS versions...and not cause a lot of programming grief with
sector alignment etc. Since I don't know the file system or the sector
size on the flash drive, using unbuffered reads causes me to have to
learn a LOT more about the drive before I proceed.

If I could just flush everything, I could let the OS worry about
all that, use the OPEN command and read away...
>
>>> Of course chkdsk is available on Windows 98 SE (it already was
> available on
>>> MS DOS 3!).
>> All I get is a message telling me to run scandisk. On win2k/xp
>> it forces an unmount then remounts the drive...flushing the READ cache.
>> Maybe I need to add some command-line parameters for 98?
>
> Post the code which calls chkdsk. But of course it is not unlikely that
> chkdsk behaves other on a Win 9x system.
>
chkdsk seems to work fine on 2k/xp. 98 is where it doesn't seem to do
anything useful to me. I don't really need this to work on 98, was just
testing it. The real issue is getting better control of the process
that lets me read directly from the hardware the FIRST time I read a file.
I'm only gonna read it once, so I don't care if subsequent reads of the
same file are chached.
**********************************************
'This calls chkdsk
dim chkme as string
chkme = "chkdsk " & Combo1.Text & " /X" 'chkdsk g: /X
Call ExecCmd(chkme, 0) 'wait forever
***********************************************
I stole this from some sample code

Private Type STARTUPINFO
cb As Long
lpReserved As String
lpDesktop As String
lpTitle As String
dwX As Long
dwY As Long
dwXSize As Long
dwYSize As Long
dwXCountChars As Long
dwYCountChars As Long
dwFillAttribute As Long
dwFlags As Long
wShowWindow As Integer
cbReserved2 As Integer
lpReserved2 As Long
hStdInput As Long
hStdOutput As Long
hStdError As Long
End Type

Private Type PROCESS_INFORMATION
hProcess As Long
hThread As Long
dwProcessID As Long
dwThreadID As Long
End Type

Private Declare Function WaitForSingleObject Lib "kernel32" (ByVal _
hHandle As Long, ByVal dwMilliseconds As Long) As Long

Private Declare Function CreateProcessA Lib "kernel32" (ByVal _
lpApplicationName As Long, ByVal lpCommandLine As String, ByVal _
lpProcessAttributes As Long, ByVal lpThreadAttributes As Long, _
ByVal bInheritHandles As Long, ByVal dwCreationFlags As Long, _
ByVal lpEnvironment As Long, ByVal lpCurrentDirectory As Long, _
lpStartupInfo As STARTUPINFO, lpProcessInformation As _
PROCESS_INFORMATION) As Long

Private Declare Function CloseHandle Lib "kernel32" (ByVal _
hObject As Long) As Long

Private Const NORMAL_PRIORITY_CLASS = &H20&
Private Const INFINITE = -1&

Public Sub ExecCmd(cmdline$, timeout&)
Dim proc As PROCESS_INFORMATION
Dim start As STARTUPINFO
'timeout of zero means wait forever
'else wait timeout& milliseconds
If timeout& = 0 Then timeout& = INFINITE
' Initialize the STARTUPINFO structure:
start.cb = Len(start)

' Start the shelled application:
ret& = CreateProcessA(0&, cmdline$, 0&, 0&, 1&, _
NORMAL_PRIORITY_CLASS, 0&, 0&, start, proc)

' Wait for the shelled application to finish:
ret& = WaitForSingleObject(proc.hProcess, timeout&)
ret& = CloseHandle(proc.hProcess)
End Sub

--
Return address is VALID!

Thorsten Albers · Joined: 04 Oct 2007 Posts: 756

mike schrieb im Beitrag
...
> The desired process is this:
> 1)Write somefiles to the flash drive.
> 2)Do some operation that forces the FIRST read of a file to be directly
> from the hardware.
> 3)Read/verify the contents of files written in step 1 ONCE.
> ...
> ...and not cause a lot of programming grief with
> sector alignment etc. Since I don't know the file system or the sector
> size on the flash drive, using unbuffered reads causes me to have to
> learn a LOT more about the drive before I proceed.

I am sorry, but as far as I can see CreateFile() with
FILE_FLAG_NO_BUFFERING is the only way to achieve what you want. Maybe
there is one other way, but I don't think that it is easier to go: A call
to function 710Dh of interrupt 21h (use DeviceIoControl() for this) causes
all file and cache buffers of a given drive to be flushed (it also allows
to remount a volume; in general it performs a drive reset).

> chkme = "chkdsk " & Combo1.Text & " /X" 'chkdsk g: /X

Just a short annotation: On Windows 9x chkdsk doesn't support an argument
'x'...

--
----------------------------------------------------------------------
THORSTEN ALBERS Universität Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------

mike · Joined: 19 Jan 2008 Posts: 29

Thorsten Albers wrote:
> mike schrieb im Beitrag
> ...
>> The desired process is this:
>> 1)Write somefiles to the flash drive.
>> 2)Do some operation that forces the FIRST read of a file to be directly
>> from the hardware.
>> 3)Read/verify the contents of files written in step 1 ONCE.
>> ...
>> ...and not cause a lot of programming grief with
>> sector alignment etc. Since I don't know the file system or the sector
>> size on the flash drive, using unbuffered reads causes me to have to
>> learn a LOT more about the drive before I proceed.
>
> I am sorry, but as far as I can see CreateFile() with
> FILE_FLAG_NO_BUFFERING is the only way to achieve what you want. Maybe
> there is one other way, but I don't think that it is easier to go: A call
> to function 710Dh of interrupt 21h (use DeviceIoControl() for this) causes
> all file and cache buffers of a given drive to be flushed (it also allows
> to remount a volume; in general it performs a drive reset).
>
>> chkme = "chkdsk " & Combo1.Text & " /X" 'chkdsk g: /X
>
> Just a short annotation: On Windows 9x chkdsk doesn't support an argument
> 'x'...
>
Int 21h seems to be a lot more direct approach to what I want to do.
Have no idea how to do it in winxp, but you've given enough clues I can
research deviceiocontrol.
Thanks,mike

--
Return address is VALID!