DosTips.com

I can measure the time T_COPY that it takes to copy a large file from one drive to another.

It takes longer to do this the first time after rebooting because the file is not in RAM so it has to be read from the Source Drive,
after which any repetition of the same source file is very much quicker.
That is normally what I want.

Sometimes I really wish to know the time taken to READ the Source Drive,
and to then repeat this measurement without the inconvenience of rebooting the P.C.

Is there a convenient method for preventing the use of the cache or flushing the cache ?
All I have thus far is :-

1. a third party utility
FASTCOPY /cmd=force_copy /auto_close
This has the disadvantage that it adds 300 to 400 mSec to the measurement whilst loading and unloading;

2. Safely Removing and then re-introducing the Source Drive
This has the disadvantages that it involves manual operations and Windows may refuse to safely remove "system drives".

Windows 7 Ultimate includes these "COPY" commands :-
COPY
XCOPY
ROBOCOPY
I find they all use the cache where possible - but perhaps you can tell me of option switches that could be of use.
Are there any other DOS commands native to CMD.EXE that might do what I need.

Is there any CMD.EXE command that a BAT script may invoke to either flush the cache or prevent its subsequent commands from reading from the caches ?

Regards
Alan

Sorry but that does not seem to serve my purpose.
I am not interested in forcing the contents of the write buffer to a drive.
I only wish to ensure that when I read from a drive that I am NOT reading from a cache the data that was previously accessed.

I have achieved my primary goal which is to measure how quickly I can write TO a drive.
My cheapest junk Flash drive manages about 5 MBytes per second when STORING a 300 MB files.
I can repeat the test and get the same result.

My secondary goal is to measure how quickly I can read FROM a drive.
My cheapest junk Flash drive manages about 16 MBytes per Second when READING a 300 MB file.
BUT every time I repeat the test it APPEARS to achieve 300 MBytes per Second,
and the only ways that I can again observe the speed of reading is to avoid the use of Windows cached data by :-
Safe removal of the drive and then reconnection;
Rebooting the computer;
or using the third party utility FASTCOPY instead of the CMD.EXE tools COPY, XCOPY, etc.
which adds an extra 300 to 400 mSec delay to the 200 mSec duration of reading a 3 MByte file

N.B. I am actually exploring the time to transfer files in the range 300 kB to 6 GB,
because I have a USB3 HDD for Partition Image backups in addition to Flash drives for MB3 audio collections.

Regards
Alan

this?

windows-file-caching

Einstein1969

einstein1969 wrote:this?

windows-file-caching

Einstein1969

Many thanks, fsutil does the job perfectly and was very easy to incorporate in my script.

Regards
Alan

But fsutil requires elevated privileges to run.

It ran O.K. with my normal authority as an administrator,
but I am happy to try any other simple method that you might like to suggest.

Regards
Alan

How does fsutil affect the timestamps on the files when used like this?

foxidrive wrote:How does fsutil affect the timestamps on the files when used like this?

No effect.
MY Flash drive F: has NTFS format and a specific file has just been processed and the these time stamp values existed on F: before and after running fsutil,
and the same values appear on the HDD that was the copy target :-

‎25 ‎November ‎2013, ‏‎20:30:14 Created
‎20 ‎March ‎2013, ‏‎13:06:20 Modified
‎25 ‎November ‎2013, ‏‎20:30:14 Accessed

Regards
Alan