• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 916
  • Last Modified:

ERROR_SHARING_VIOLATION when trying to read timestamp from network shared file

I have to show the timestamp (change time) für an EXE within the program, and this works if the file ist called from the local hard drive. When called from a network share, I receive an error. When examining the "properties" of the shared file, I am owner, and I have full access.

This is the code:
STDMETHODIMP CKonfiguration::GetFileChangeTime(/*[in]*/ BSTR bsDateiMitPfad, /*[out]*/ BSTR * bsZeitstempel)
	*bsZeitstempel = NULL;

	// unsinnigen Dateinamen abfangen
	if (SysStringLen(bsDateiMitPfad) <= 1)
		return S_FALSE;

	HANDLE hFile = CreateFile(bsDateiMitPfad, GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);
	DWORD dwLastError = GetLastError();

		return S_FALSE;

	FILETIME ftCreationTime, ftLastAccessTime, ftLastWriteTime, ftLocal;
	BOOL bSuccess = GetFileTime(hFile, &ftCreationTime, &ftLastAccessTime, &ftLastWriteTime);
	dwLastError = GetLastError();

Open in new window

CreateFile gives me INVALID_HANDLE_VALUE, and the LastError is ERROR_SHARING_VIOLATION. The call is from within the EXE herself, she tries to find out her own timestamp. GetFileTime must be called with a file handle opened with GENERIC_READ says the documentation, so this is no point for further fiddling.

The server where the share is physically located is a Windows Server 2003 and in the same domain as the client accessing it.

This is VB6, but I had to put it into the .NET zone, because there is no other fitting any more :-(

Any ideas ?
1 Solution
Are you sure the path in bsDateiMitPfad is correct when you pull it off the network share?
You are using a mapped drive, right?
AndyAinscowFreelance programmer / ConsultantCommented:
Does this cure it?

From the help files about CreateFile:

Windows Server 2003 and Windows XP/2000:  A sharing violation occurs if an attempt is made to open a file or directory for deletion on a remote computer when the value of the dwDesiredAccess parameter is the DELETE access flag OR'ed with any other access flag, and the remote file or directory has not been opened with FILE_SHARE_DELETE. To avoid the sharing violation in this scenario, open the remote file or directory with the DELETE access right only, or call DeleteFile without first opening the file or directory for deletion.

I suggest you play a little with the settings - even if you open it with the DELETE rights then you don't actually have to delete it.

PC-AlexAuthor Commented:
Yes, that was it, thanks a lot for the fast help
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now