Opening and Reading the locked files

[Shrishail Rana]

Hi

I need to backup some of the exclusive locked files. I have tried many ways
to call CreateFile but it fails either by giving sharing violation or Access
Denied. I have backup and restore privilege.

What flags shall I CreateFile to open the locked File for backup

In the below code I can atleast open the file but any changes to it are
denied.
HANDLE hfile = CreateFile(strFilename, READ_CONTROL, 0, 0,OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS, 0 );

Now this open's the file but ReadFile and BackupRead Fails. ReadFIles fails
with exception CreateFile Failed : Access Denied. But I have a valid handle.
BackupRead causes Access Violation.

Best regards

Shrishail Rana

[Tom Stewart]

"Shrishail Rana" <sr...@hotpop.com> wrote in message
news:eO9jasIe...@TK2MSFTNGP12.phx.gbl...

> Hi
>
> I need to backup some of the exclusive locked files. I have tried many ways
> to call CreateFile but it fails either by giving sharing violation or Access
> Denied. I have backup and restore privilege.

This is why there are products that do this, acting as file system filter drivers, e.g. St.
Bernard Software's Open File Manager (hope I'm remembering all that correctly). If the file
is open with SHARE_NONE then you won't have any luck without some help (i.e. filter driver).

>
> What flags shall I CreateFile to open the locked File for backup
>
> In the below code I can atleast open the file but any changes to it are
> denied.
> HANDLE hfile = CreateFile(strFilename, READ_CONTROL, 0, 0,OPEN_EXISTING,
> FILE_FLAG_BACKUP_SEMANTICS, 0 );
>
> Now this open's the file but ReadFile and BackupRead Fails. ReadFIles fails
> with exception CreateFile Failed : Access Denied. But I have a valid handle.

You may have a handle, but it's a handle without GENERIC_READ, which you need to read the
data. That's why you get access denied.

[Rhett Gong [MSFT]]

Hi Shrishail,
For such files, you could workaround it by adding SE_BACKUP_NAME and SE_RESTORE_NAME
access privileges to your process token. Then call CreateFile as you did before:

> HANDLE hfile = CreateFile(strFilename, READ_CONTROL, 0, 0,OPEN_EXISTING,
> FILE_FLAG_BACKUP_SEMANTICS, 0 );

At this time, your process gets the abilities to read or override the access-control
settings of the target files. Then calling GetKernelObjectSecurity and
SetKernelObjectSecurity before BackupRead.

Please feel free to let me know if you need further assist on this problem.

Best regards,
Rhett Gong [MSFT]
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only. Thanks.

[Gary Chanson]

"Rhett Gong [MSFT]" <v-ra...@online.microsoft.com> wrote in message
news:52uCrFS...@cpmsftngxa10.phx.gbl...

> Hi Shrishail,
> For such files, you could workaround it by adding SE_BACKUP_NAME and
SE_RESTORE_NAME
> access privileges to your process token. Then call CreateFile as you did
before:
> > HANDLE hfile = CreateFile(strFilename, READ_CONTROL, 0, 0,OPEN_EXISTING,
> > FILE_FLAG_BACKUP_SEMANTICS, 0 );
>
> At this time, your process gets the abilities to read or override the
access-control
> settings of the target files. Then calling GetKernelObjectSecurity and
> SetKernelObjectSecurity before BackupRead.

I thought that this would only override ownership but not sharing
conflicts.

--
-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
- http://www.mvps.org/ArcaneIncantations/consulting.htm
-gcha...@mvps.org

[Shrishail Rana]

Hi Rhett

Did'nt worked :(. It gives
Create File does not have access to the file.

Best regards

Shrishail Rana

"Rhett Gong [MSFT]" <v-ra...@online.microsoft.com> wrote in message
news:52uCrFS...@cpmsftngxa10.phx.gbl...

[Rhett Gong [MSFT]]

Hi,

>Did'nt worked :(. It gives
>Create File does not have access to the file.

If the sharemode is specified as 0 (SHARE_NONE), it should return
ERROR_SHARING_VIOLATION. And as Tom and Gary pointed out, it is hard to work around
the share violation. But if the file is openned in another process with SHARE_READ,
then calling BackupRead should not cause access denied. Could you tell us what you got
from GetLastError after CreateFile failed?

[Shrishail Rana]

Hi

it gives access denied. CreateFile Failed.

Best regards

Shrishail Rana

#define _UNICODE
#define UNICODE
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include "assert.h"

void Quit( const wchar_t* pszMsg, int nExitCode = 1 )
{
wprintf( L"%s\n", pszMsg );
exit( nExitCode );
}

// brain-dead error routine that dumps the last error and exits
void Err( const wchar_t* pszFcn, DWORD nErr = GetLastError() )
{
wchar_t szErr[256];
wchar_t szMsg[512];
if ( FormatMessage( FORMAT_MESSAGE_FROM_SYSTEM, 0, nErr, 0,
szErr, sizeof szErr / sizeof *szErr, 0 ) )
swprintf( szMsg, L"%s failed: %s", pszFcn, szErr );
else swprintf( szMsg, L"%s failed: 0x%08X", nErr );
Quit( szMsg );
}

// Useful helper function for enabling a single privilege
bool EnablePrivilege( HANDLE htok, const wchar_t* pszPriv,
TOKEN_PRIVILEGES& tpOld )
{
TOKEN_PRIVILEGES tp;
tp.PrivilegeCount = 1;
tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
if ( !LookupPrivilegeValue( 0, pszPriv, &tp.Privileges[0].Luid ) )
Err( L"LookupPrivilegeValue" );

// htok must have been opened with the following permissions:
// TOKEN_QUERY (to get the old priv setting)
// TOKEN_ADJUST_PRIVILEGES (to adjust the priv)
DWORD cbOld = sizeof tpOld;
if ( !AdjustTokenPrivileges( htok, FALSE, &tp, cbOld, &tpOld, &cbOld ) )
Err( L"AdjustTokenPrivileges" );

// Note that AdjustTokenPrivileges may succeed, and yet
// some privileges weren't actually adjusted.
// You've got to check GetLastError() to be sure!
return ( ERROR_NOT_ALL_ASSIGNED != GetLastError() );
}

// Corresponding restoration helper function
void RestorePrivilege( HANDLE htok, const TOKEN_PRIVILEGES& tpOld )
{
if ( !AdjustTokenPrivileges( htok, FALSE,
const_cast<TOKEN_PRIVILEGES*>(&tpOld),
0, 0, 0 ) )
Err( L"AdjustTokenPrivileges" );
}

// Brain-dead print routine for brevity
void PrintFile( HANDLE h )
{
DWORD cb = GetFileSize( h, 0 );
assert(cb);
void* psz = malloc( cb );
ZeroMemory(psz, cb);

ReadFile( h, psz, cb, &cb, 0 );
Err( L"CreateFile" );
DWORD byter = 0;
BackupRead(h, (LPBYTE) psz, 100, &byter, false, false, NULL );
BackupRead(h, (LPBYTE)NULL, cb, &byter, true, false, NULL );
WriteFile( GetStdHandle( STD_OUTPUT_HANDLE ), psz, cb, &cb, 0 );
free( psz );
}

void wmain( int argc, wchar_t* argv[] )
{

// Enable the backup privilege
HANDLE htok = 0;
if ( !OpenProcessToken( GetCurrentProcess(),
TOKEN_QUERY | TOKEN_ADJUST_PRIVILEGES, &htok ) )
Err( L"OpenProcessToken" );
TOKEN_PRIVILEGES tpOld;
if ( !EnablePrivilege( htok, SE_BACKUP_NAME, tpOld ) )
Quit( L"Sorry, you don't have the backup privilege..." );
EnablePrivilege( htok, SE_RESTORE_NAME, tpOld );
EnablePrivilege( htok, SE_TCB_NAME, tpOld );
// Open the requested file, exercising the backup privilege
HANDLE hfile = CreateFile( L"e:\\documents and settings\\sr\\ntuser.dat",
GENERIC_READ | READ_CONTROL, 0, 0,
OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0 );
if ( INVALID_HANDLE_VALUE == hfile )
Err( L"CreateFile" );

// Now restore the privilege back to its prior state.
// This is not strictly necessary, since we're going
// to terminate the process anyway, and the token we've
// adjusted will be destroyed, but in real life you might
// have processes that do a little more than this :-)
//RestorePrivilege( htok, tpOld );

// Note that once we've got the file handle opened, we can
// use the permissions we were granted via CreateFile.
// There are no further access checks performed.
PrintFile( hfile );

CloseHandle( hfile );
CloseHandle( htok );
}

[Tony Proctor]

I have to question the logic in backing up files that are exclusively
locked. OK, if it's a simple text file then it would serve some purpose.
However, if it's a binary file with an internal structure then the contents
may be "inconsistent" while the lock is active. In other words, the backed
up copy may, to all intents and purposes, be useless as a historical copy,
and appear as simply a corrupt copy of the original.

Tony Proctor

"Shrishail Rana" <sr...@hotpop.com> wrote in message
news:eO9jasIe...@TK2MSFTNGP12.phx.gbl...

[Rhett Gong [MSFT]]

Hi,
Call GetLastError after the CreateFile when the file handle is invalid and let me know
the return value from GetLastError please.
Could you tell what share mode the target file is openned by another process?
FILE_SHARE_READ, FILE_SHARE_WRITE or something else?

[Shrishail Rana]

When I use FILE_SHARE_READ or FILE_SHARE_WRITE or both I cannot open the
file. Only way to open the file is
to pass 0 for sharing.

--

Best regards

Shrishail Rana

"Rhett Gong [MSFT]" <v-ra...@online.microsoft.com> wrote in message

news:Bo2fc2s...@cpmsftngxa06.phx.gbl...

[Rhett Gong [MSFT]]

>When I use FILE_SHARE_READ or FILE_SHARE_WRITE or both I cannot open the
>file. Only way to open the file is
>to pass 0 for sharing.

Suppose you have 2 processes using this file (p1 performs some actions on the file,
while p2 is used to backup/restore the file) :
1> if p1 open this file with FILE_SHARE_READ, then p2 can createfile with
FILE_SHARE_READ and perform read operation on this file such as BackupRead to backup
the file.
2> if p1 open this file with FILE_SHARE_WRITE, then p2 can perform write operation such
as BackupWrite.
3>if p1 succeed createfile with 0 (SHARE_NONE). Then any subsequent attempt to open
this file will cause share violation. And there is no better way to workaround this,
since it would mess up the file if 2 processed are writing to it at the same time.

Thanks,

[Shrishail Rana]

Hi

Thank you for your help. Will search more.

Best regards

Shrishail Rana

"Rhett Gong [MSFT]" <v-ra...@online.microsoft.com> wrote in message

news:G5448P2e...@cpmsftngxa06.phx.gbl...

[Rhett Gong [MSFT]]

Thanks for your feedback.

If you get anyting more, please feel free to post it here. We could work
together to get further information on this problem.

Have a good day!