Access Denied when saving file in NT server

Hi,

my application is SDI and uses MFC architecture.

When it runs from my computer (XP Pro) works fine and saves the files in the server (Windows 2003).

When it runs from other computers (Windows 2000 Pro) it does not save the document in the server and reports the "Access to file .... denied" error. The application works fine when the file resides on the local PC.

All users have full access to the server and to the specific file.

Debugging the code, i have noticed that the Kernel 32 function "ReplaceFile" called from the CDocument class fails when the program runs in Windows 2000.

Any ideas to overcome this?

Thanks in advance.

I suppose it's really a problem of access-rights. Check if the user under which your application is running has access not only to the file but to the folders above and to the network-drive. Better check twice, I spend some time on such a problem until I find the missing access-right :sick:

Quote:

---

Originally Posted by martho

I suppose it's really a problem of access-rights. Check if the user under which your application is running has access not only to the file but to the folders above and to the network-drive. Better check twice, I spend some time on such a problem until I find the missing access-right :sick:

---

User has full access to the whole directory. User is allowed to manually delete/rename the file.

Note that:

I've halted the code just prior to the execution of "ReplaceFile" function. Next, i've manually deleted the replaced file (windows explorer) and continued the program. Although the function returns false (it does not find the replaced file) the temporary file is saved and the error message is suppessed.

Anybody of any kind of help?

Definition of _WIN32_WINNT and WINVER macros (MSDN) didn't help.

The problem seems to be a bug in Windows 2000 only.
Perhaps Microsoft has more urgent things to do (i.e. releasing anti-exploit hotfixes) than helping programmers out.

I can confirm that the problem does *not* exist when you invoke the "ReplaceFile" method under Windows XP. And it works fine under Windows NT4 too (and noone needed to know that, but what the heck ;-) )

- - -

I have just written a work-around that kicks in under Windows 2000 only. All other Windows versions will perform as hitherto.

In Visual Studio 6 I right clicked the document class and added a virtual function "OnSaveDocument".
I then entered the following contents (hope it'll be readable when I Ctrl+V Paste it in):

BOOL MyDoc::OnSaveDocument(LPCTSTR lpszPathName)
{
// Coffee Zombie: Modified 2005-11-02:
//return CDocument::OnSaveDocument(lpszPathName);

bool bDoWin2kWorkAround = false;
char* pcBakFile = NULL;

OSVERSIONINFO OSinf;
OSinf.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx(&OSinf);

if (OSinf.dwPlatformId==VER_PLATFORM_WIN32_NT) // Windows NT 3, Windows 2000 or Windows XP or newer (not Win3.x or Win95 to WinME)
{
if (OSinf.dwMajorVersion==5) // Windows 2000 or XP
{
if (OSinf.dwMinorVersion==0) // Windows 2000
{
// Must do a work-around for buggy ReplaceFile method in KERNEL32 under Windows 2000 only:
pcBakFile = new char[strlen(lpszPathName)+10];
if (pcBakFile!=NULL) // Avoid out-of-memory errors:
{
// Rename any existing file to "*.*.bak":
strcpy(pcBakFile,lpszPathName);
strcat(pcBakFile,".bak");
::remove(pcBakFile); // Ignore error
DWORD dwRc = ::rename(lpszPathName,pcBakFile);
if (dwRc==0)
bDoWin2kWorkAround = true; // We succeded in renaming an existing file!
else
{
// We did not succeed in renaming the existing file.
// This either means that no file exists, or that some access priviledge is missing.
// Ignore error and fall through to normal behaviour: ....
}
}
}
}
}

BOOL bSuccess = CDocument::OnSaveDocument(lpszPathName);

if (bDoWin2kWorkAround)
{
if (bSuccess)
{
// We did it!
// Now clean up:
::remove(pcBakFile);
// Ignore error. After all it's only a temp file.
}
else
{
// An error occurred!
// Rename the original file back:
try
{
CFile::Rename(pcBakFile,lpszPathName);
}
catch (CFileException exFile)
{
exFile.ReportError();
}
}
}

if (pcBakFile!=NULL)
{
delete pcBakFile;
pcBakFile = NULL;
}

return bSuccess;
// .. Coffee Zombie
} // MyDoc::OnSaveDocument

Ok then... I'll attach a file next time!

Hello C Z,

From MSDN on CreateFile(...) - I'm not sure if this may help.

Jeff

Quote:

---

Files

If you try to create a file on a floppy drive that does not have a floppy disk or a CD-ROM drive that does not have a CD, the system displays a message for the user to insert a disk or a CD. To prevent the system from displaying this message, call the SetErrorMode function with SEM_FAILCRITICALERRORS.

Windows Server 2003 and Windows XP/2000: If CREATE_ALWAYS and FILE_ATTRIBUTE_NORMAL are specified, CreateFile fails and sets the last error to ERROR_ACCESS_DENIED if the file exists and has the FILE_ATTRIBUTE_HIDDEN or FILE_ATTRIBUTE_SYSTEM attribute. To avoid the error, specify the same attributes as the existing file.

For more information, see Creating and Opening Files.


If you rename or delete a file and then restore it shortly afterward, the system searches the cache for file information to restore. Cached information includes its short/long name pair and creation time.

Windows Me/98/95: This remark does not apply.

If you call CreateFile on a file that is pending deletion as a result of a previous call to DeleteFile, the function fails. The operating system delays file deletion until all handles to the file are closed. GetLastError returns ERROR_ACCESS_DENIED.

---

Hi Jeff: My problem is like this:

We have several MFC applications developed in Visual Studio 97 for WinNT4. Generally they work fine under Windows 2000 and XP, but when we try to save a file that already exists on a Win2000 file server, that operation will fail with an Access Denied = 0x00000005 error. But only - and this is the weird part - when the client computer is Windows 2000. The exactly same thing works fine on a client running WinNT or WinXP.
An especially nasty twist to this problem is, that if the user starts experimenting with a "Save As.." in stead and enters the original name, this will not only still fail with an Access Denied error, but as an effect the original file will disappear!

The file has only the Archive attribute set, not System or Readonly.
As for Security Attributes my company doesn't allow us to edit them for any files on our network shares - not even the ones we're marked as Owner for.
We have 'Modify' access to the files we own. If I look at the detailed list of persmissions, the only ticks missing are 'Delete Subfolders and Files', 'Change Permissions' and 'Take Ownership'.

If I write a text in Notepad or Word I can save and re-save that file with no problems.

My work-around (the lines of code that I pasted into my previous posting) renames the original file, then allows MFC to do its <b>ReplaceFile</b> trick (not the CreateFile you mention), and finally cleans up.
It's a bit clumsy but it works. And since saves aren't done all that often and people don't tend to work on the same file from more than one client pc at a time, I think it'll have to do.
Moreover all clients will be converted to Windows XP over the next 12 months or so.


I have tried recompiling under Visual Studio 6 but that changed nothing.
The MFC42.DLL is version 6.0.9586.0 from 2003-06-19 which I believe is the most resent. Anyway - that shouldn't be important, since the 'ReplaceFile' call is made directly to KERNEL32 - see this excerpt from the method CMirrorFile::Close() from the MFC file named DOCCORE.CPP:
if (!afxData.bWin95)
{
HMODULE hModule = GetModuleHandleA("KERNEL32");
ASSERT(hModule != NULL);

pfn = (ReplaceAPIPtr) GetProcAddress(hModule, "ReplaceFile");

if (pfn != NULL)
{
USES_CONVERSION;

strBackupName = GetTempName(m_strMirrorName, FALSE);

// this NT API handles copying all attributes for us

bWorked = (pfn)(T2W((LPTSTR)(LPCTSTR)m_strName),
T2W((LPTSTR)(LPCTSTR)m_strMirrorName),
T2W((LPTSTR)(LPCTSTR)strBackupName),
REPLACEFILE_WRITE_THROUGH | REPLACEFILE_IGNORE_MERGE_ERRORS,
NULL, NULL);

if (!bWorked)
dwResult = GetLastError();
}
}

- - -

For skoutso, who posted the original message: did you find a solution?

Hi CZ,

This is a bit OT, but here goes.

One of my help desk technicians had a similar (not exact) problem under Windows XP workstation and Windows 2000 Server. In the end, we rejoined her computer to the domain.

Quote:

---

We have 'Modify' access to the files we own.

---

The Security Attributes property page will sometimes lie to you. Use cacls.exe instead for problems like yours when investigating permission issues.

Also, CODE tags on your post would improve readability :).

Jeff

Coffee Zombie / Jeffrey

Many thanks for your replies.

I had worked out the problem in a way much similar to Coffee Zombie Code.
The key is to use MFC to replace the file and not KERNEL.

I haven't tried CZ Code yet but I don't see why it shouldn't work.