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.
> 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.
> 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 ?
> 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.
"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/file... 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...
> 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.
|
