Does mountvol flush the buffer cache?

Dear All,

I would like to save some files onto external USB drives (OS is
Windows 2000). This should happen automatically: Users just plug in
the drive and leave the machine running. Sometime later (at night) a
batch job starts and copies files over. The next day the user unplugs
the drive and plugs in a new one.

My question is the following: Windows 2000/XP/2003 provide the
mountvol command to dynamically assign partitions to drive letters and
also to detach a drive letter from a partition. Partions are accessed
using Volume IDs. To mount a partition onto drive X: one would use
something like

mountvol X: \\?\Volume{bdeb2ff0-5c91-11d8-a7b0-806e6f6e6963}\

where \\?\Volume{bdeb2ff0-5c91-11d8-a7b0-806e6f6e6963}\ is the Volume
ID. (Btw. does somebody know where those IDs are stored? In the partition
table? File system?).

To unmount X:

mountvol X: /D

The question now is if "mountvol X: /D" will also flush the buffer
cache of the file system on that partition, or in other words, if it
would be safe to unplug the drive after detaching the drive letter?
Alternatively, there is the "sync" utility from Sysinternals that has
equivalent functionality to Unix sync. Is that enough to make sure all
data is on the drive?


Many thanks in advance,

--

Joerg Lenneis

email:

The question now is if "mountvol X: /D" will also flush the buffer
cache of the file system on that partition, or in other words, if it
would be safe to unplug the drive after detaching the drive letter?
Alternatively, there is the "sync" utility from Sysinternals that has
equivalent functionality to Unix sync. Is that enough to make sure all
data is on the drive?

Yes.

Both can be used.

On the first sight, dismount looks better then sync due to lack of possible
window where the cache can be dirtied after sync. Nevertheless, on Windows,
this is not so. Windows has the Linux-style "autofs" functionality hardcoded to
the kernel and it is impossible to switch if off. So, it will remount the FS to
the block device on the very next CreateFile targeted at this drive letter.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com

Maxim S Shatskih:

[...]

Yes.

Both can be used.

On the first sight, dismount looks better then sync due to lack of possible
window where the cache can be dirtied after sync. Nevertheless, on Windows,
this is not so. Windows has the Linux-style "autofs" functionality hardcoded to
the kernel and it is impossible to switch if off. So, it will remount the FS to
the block device on the very next CreateFile targeted at this drive letter.

[...]

Maxim,

thank you for your answer. Just to make sure I get this right, do the
comments (starting with ##) I have added to the following sequence of
commands make sense?


## mount a partition onto drive X: and copy some files to it
mountvol X: \\?\Volume{bdeb2ff0-5c91-11d8-a7b0-806e6f6e6963}\
copy *.* X:
## sync the drive and unmount
sync X:
mountvol X: /D
## The partition is still available as
## \\?\Volume{bdeb2ff0-5c91-11d8-a7b0-806e6f6e6963}\ and could
## be remounted. All files and metadata written so far are safe.
## If we unplug the drive now, \\?\Volume{bdeb2ff0-5c91-11d8-a7b0-806e6f6e6963}\
## will disappear without causing data corruption to files created so far.


OK, so if after all this has happened, I do something like

copy somefile X:

this would result in \\?\Volume{bdeb2ff0-5c91-11d8-a7b0-806e6f6e6963}\
being remounted onto X:?

best regards,




--

Joerg Lenneis

email:

thank you for your answer. Just to make sure I get this right, do the
comments (starting with ##) I have added to the following sequence of
commands make sense?

A bit hard for me to look at them, I'm more convinient with doing this in C
code.

For clean dismount:

hFile = CreateFile(\\.\E - where E: is a drive letter
DeviceIoControl(hFile, FSCTL_LOCK_VOLUME...);
DeviceIoControl(hFile, FSCTL_DISMOUNT_VOLUME...);
DeviceIoControl(hFile, FSCTL_UNLOCK_VOLUME...);
CloseHandle(hFile);

The LOCK IOCTL will fail if there are open files of the volume - like the
UNIX's "Mount device busy" error.

For abrupt dismount with tearing away the open files (dunno whether UNIXen can
do such) - the same code as the above, but omit LOCK and UNLOCK. This will
cause all open files to be invalidated, and all IO on them failed.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com