Cannot open ifstream in non-shared mode on Windows 2008 Server

Dear All!

I have a problem with opening file in non-shared mode on Windows 2008 server using ifstream object. My code works fine on Windows XP, but as soon as I try to run it on Windows 2008 Server, the file open fails with errno value 13 (permission denied). I have "Full Control" rights over the file and the folder containing the file. The file is not open by any other users, as it can be renamed and moved to the other folder. In case of both operating systems the file is located on a local drive, not on a network share. The line in my code opening the file is as follows: (ifname, ios::in | ios::binary, filebuf::sh_none);

where inpfile is an object of class ifstream.

If I remove the "filebuf::sh_none" parameter, it works fine also on Windows 2008. However, I would like to make sure that no one else is accessing the file at the same time (so I need the exclusive mode), that's why I used protection specification sh_none.

What could be the possible reason of such behaviour? Does someone have the same experience?

I am using the old Microsoft Visual C++ 6.0 - perhaps it's just too old to compile a program to be used on Windows 2008...

I would be happy if someone could share some experience. Thanks in advance!
Who is Participating?
jkrConnect With a Mentor Commented:
Well, to be blunt - 'filebuf::sh_none' is definitely not a valid member of 'ios_base::openmode' ( Anyway, opening files in 'exclusive' mode is highly OS specific and therefore not covered by the C++ standard. However, the discussion at ("filebuf::sh_none - compiler error") and the followup at might helpt - try (ifname, ios::in | ios::binary, _SH_DENYRW);

instead (even though I'd still prefer to use the Wiindows API for such a purpose).
I agree with JKR, if you are doing file locking, etc. on Windows, I'd prefer to use the CreateFile() and other Win32 methods. They are closer to the OS, as far as debugging what the heck is going wrong. I usually use a thin layer of abstraction with conditional compilation across UNIX or Windows.

If your code never needs to run any non-Win32 platforms, then Win32 API is the customary way to code anyway. The C++ iostreams lib has changed a bit over the years (especially since VC 6) and in my opinion is too bloated and complex, compared to Win32 or STDIO (C).
Todd GerbertIT ConsultantCommented:
I'm not nearly as knowledgeable as jkr or mrjoltcola, so you're probably better off following their advice than mine - plus this more of a "why it happens" comment, not a "how to resolve it" (at least an educated guess at any rate).

If it works under XP but not Server 2008 the first thing that comes to my mind is UAC.  Certain folders, like Program Files, are protected by UAC - so that even if you login as an administrator and/or have full access to a file in C:\Program Files somewhere, unless you right-click on the executable and specifically choose "Run as Administrator..." UAC will cause a permission denied.
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

trinitrotolueneDirector - Software EngineeringCommented:
I have run into a similar situation on WS2008 and I got round it by using this API and passing _SH_DENYNO  as the mode.

However I agree with what tgerbert is saying because there are still cases where I've seen my program fail with an error code 13 especially when I access files under %windir%/System32

So I too would suggest using the Windows API in your case and maybe try moving to a later version of the compiler (VS2005, VS2008 or VS2010)
trinitrotolueneDirector - Software EngineeringCommented:
Todd GerbertIT ConsultantCommented:

If the file you're trying to access is anywhere under C:\Program Files or C:\Windows you're application will probably need to be run elevated (the user can right-click a shortcut and choose Run as administrator; you can include a UAC manifest with your executable so Windows will automatically prompt the user to elevate it; your application can use ShellExecute to re-launch itself with the runas verb; you can use a system policy to always run everything elevated - i.e. disable UAC).  However, unless absolutely necessary, you should consider using a location in the users' profile, or in %ALLUSERSPROFILE%.

If the file in question is not under %WinDir% or %ProgramFiles% then UAC might not have anything to do with your problem.

Embed a UAC manifest:

evilrixSenior Software Engineer (Avast)Commented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
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.

All Courses

From novice to tech pro — start learning today.