non admin FlushFileBuffers for a volume
Jack Anderson
In our software we need to flush all the data on a removable device(disk
on key). The problem is that when user is non admin we can't obtain
handle to the volume using CreateFile cause of the insufficient
privileges. I'm looking for a work around to cause file/cache manager to
flush all the data.
Btw eject is not an option for us as after flushing we are doing some
operation via disk on keys firmware that cause it to show "private"
folders, if we do this without flush the data is lost on Win2k machines
where Performance check box is by default turned on on disk on keys.
Thanks in advance
Vladimir Scherbina
You can get a handle to volume by running under administration privileges
only. It means that you can use impersonation for performing your task.
--
Vladimir (Windows SDK MVP)
"Jack Anderson" <sp...@spam.org> wrote in message
news:usaksUkq...@TK2MSFTNGP03.phx.gbl...
Jack Anderson
> Hi Jack!
>
> You can get a handle to volume by running under administration
> privileges only. It means that you can use impersonation for performing
> your task.
>
Thanks for your answer Vladimir,
Unfortunetly impersonation is not possible for us, its a simple client
software...
We found a "hack" which seems to be working for us, and it does flush I
would like you to give me your opinion and maybe to explain why it seems
to work, what we do is call CreateFile on a root director e.g. "C:\"
with FILE_FLAG_BACKUP_SEMANTICS flag and then call FlushFileBuffers,
this seems to go over all the "children" directories/files that were
just created and flush.
Any ideas why this works or if it might not work in certain circumstances ?
Thanks in advance
Vladimir Scherbina
[..]
> We found a "hack" which seems to be working for us, and it does flush I
> would like you to give me your opinion and maybe to explain why it seems
> to work, what we do is call CreateFile on a root director e.g. "C:\" with
> FILE_FLAG_BACKUP_SEMANTICS flag and then call FlushFileBuffers, this seems
> to go over all the "children" directories/files that were just created and
> flush.
[..]
> Any ideas why this works ...
FILE_FLAG_BACKUP_SEMANTICS flag does all magic. From
MSDN(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_security_and_access_rights.asp):
"There are situations when a backup application must be able to change the
access control settings of a file or directory. An example is when the
access control settings of the disk-resident copy of a file or directory is
different from the backup copy. This would happen if these settings were
changed after the file or directory was backed up, or if it was corrupted.
The FILE_FLAG_BACKUP_SEMANTICS flag specified in the call to CreateFile
gives the backup application process permission to read the access-control
settings of the file or directory. With this permission, the backup
application process can then call GetKernelObjectSecurity and
SetKernelObjectSecurity to read and than reset the access-control settings."
Seems like mentioned above documentation applies to volumes (not only the
files). This makes contradiction with documentation written for
CreateFile(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp):
You can use the CreateFile function to open a physical disk drive or a
volume. The function returns a handle that can be used with the
DeviceIoControl function. This enables you to access the disk partition
table. However, it is potentially dangerous to do so, because an incorrect
write to a disk could make its contents inaccessible. The following
requirements must be met for such a call to succeed:
a.. *The caller must have administrative privileges. For more information,
see Running with Special Privileges.*
b.. The dwCreationDisposition parameter must have the OPEN_EXISTING flag.
c.. When opening a volume or floppy disk, the dwShareMode parameter must
have the FILE_SHARE_WRITE flag.
> ... or if it might not work in certain circumstances ?
IMO MS has two possible variants: change the documentation or change the
implementation of CreateFile...
Slava M. Usov
[...]
> We found a "hack" which seems to be working for us, and it does flush I
> would like you to give me your opinion and maybe to explain why it seems
> to work, what we do is call CreateFile on a root director e.g. "C:\" with
> FILE_FLAG_BACKUP_SEMANTICS flag and then call FlushFileBuffers, this seems
> to go over all the "children" directories/files that were just created and
> flush.
>
> Any ideas why this works or if it might not work in certain circumstances
> ?
You can open the root directory because either the file system is FAT or the
security descriptor of the root directory is liberal enough. One of these
two conditions will probably apply to the majority of removable media.
This does not explain why flushing the root directory flushes all the other
directories and files. This behaviour happens to be undocumented. However,
the FAT file system driver does indeed flush the entire volume when the root
directory is flushed.
Bottom line, if your device is formatted with FAT, your technique will
always work. If it is NTFS, not necessarily.
S