fopen fails to give error when UAC is enabled
-
Hi, I have a use case to validate an path that is given as an input to my application. I tried to create a file in the path with fopen and added the following check : FILE *fp= fopen(Input path, "w"); if( fp == NULL) { //Invalid path } else { //Valid path } This works well for cases when the input path is invalid or not present. But in certain cases, when UAC is enabled, a file cannot be created in the C:\Program files location. So in that scenario, if my input path is C:\Program files, fopen doesnt return any error and above code executes the else part, which is wrong. Can anyone please provide suggestions about this issue? Sindhu
-
Hi, I have a use case to validate an path that is given as an input to my application. I tried to create a file in the path with fopen and added the following check : FILE *fp= fopen(Input path, "w"); if( fp == NULL) { //Invalid path } else { //Valid path } This works well for cases when the input path is invalid or not present. But in certain cases, when UAC is enabled, a file cannot be created in the C:\Program files location. So in that scenario, if my input path is C:\Program files, fopen doesnt return any error and above code executes the else part, which is wrong. Can anyone please provide suggestions about this issue? Sindhu
How about using PathIsDirectory[^]?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
-
How about using PathIsDirectory[^]?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
Thanks. But PathIsDirectory() might not tell me if the user has write access to that path right?
-
Thanks. But PathIsDirectory() might not tell me if the user has write access to that path right?
-
Hi, I have a use case to validate an path that is given as an input to my application. I tried to create a file in the path with fopen and added the following check : FILE *fp= fopen(Input path, "w"); if( fp == NULL) { //Invalid path } else { //Valid path } This works well for cases when the input path is invalid or not present. But in certain cases, when UAC is enabled, a file cannot be created in the C:\Program files location. So in that scenario, if my input path is C:\Program files, fopen doesnt return any error and above code executes the else part, which is wrong. Can anyone please provide suggestions about this issue? Sindhu
sindhumahe wrote:
if my input path is C:\Program files, fopen doesnt return any error and above code executes the else part, which is wrong.
Just for grins, have you tried using
fp
in theelse
part?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
Hi, I have a use case to validate an path that is given as an input to my application. I tried to create a file in the path with fopen and added the following check : FILE *fp= fopen(Input path, "w"); if( fp == NULL) { //Invalid path } else { //Valid path } This works well for cases when the input path is invalid or not present. But in certain cases, when UAC is enabled, a file cannot be created in the C:\Program files location. So in that scenario, if my input path is C:\Program files, fopen doesnt return any error and above code executes the else part, which is wrong. Can anyone please provide suggestions about this issue? Sindhu
Perhaps you are simplifying your code example, but the condition of fp == NULL could be true for many more reasons than just invalid path. You might want to make a call to GetLastError[^]. The returned error number will allow you to detect all manor of error conditions. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
-
Hi, I have a use case to validate an path that is given as an input to my application. I tried to create a file in the path with fopen and added the following check : FILE *fp= fopen(Input path, "w"); if( fp == NULL) { //Invalid path } else { //Valid path } This works well for cases when the input path is invalid or not present. But in certain cases, when UAC is enabled, a file cannot be created in the C:\Program files location. So in that scenario, if my input path is C:\Program files, fopen doesnt return any error and above code executes the else part, which is wrong. Can anyone please provide suggestions about this issue? Sindhu
Whenever something is different when UAC is enabled, the first question to ask is "does your application have a security manifest?" and if so, "is it setup properly?" In a nutshell, the presence of the security manifest will prevent things like "file virtualization" and "registry virtualization" and when setup properly will make your application act like it did before UAC was ever invented (i.e. intuitive when code works and doesn't work and why).
-
Perhaps you are simplifying your code example, but the condition of fp == NULL could be true for many more reasons than just invalid path. You might want to make a call to GetLastError[^]. The returned error number will allow you to detect all manor of error conditions. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
Chris Meech wrote:
You might want to make a call to GetLastError[^].
Does
fopen()
callSetLastError()
? I would have thought it would useerrno
instead."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
Chris Meech wrote:
You might want to make a call to GetLastError[^].
Does
fopen()
callSetLastError()
? I would have thought it would useerrno
instead."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
Good point. I've become so used to calling GetLastError to solve things, but you may be correct that errno could be checked instead. :-O [EDIT] And now that I've checked fopen[^] in MSDN, it does set errno. :slaps head: :doh:
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
-
Good point. I've become so used to calling GetLastError to solve things, but you may be correct that errno could be checked instead. :-O [EDIT] And now that I've checked fopen[^] in MSDN, it does set errno. :slaps head: :doh:
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
You could be right, too, if
fopen()
is simply a wrapper aroundCreateFile()
."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous