File.Exists

[sur]

Hello,

My problem is that File.Exists works fine if my file is on my local
drive but returns false if its on any other drive. I think that the
issue is probably file permissions and so I have tried the following:

FileIOPermision permFileIO = new
FileIOPermission(FileIOPermissionAccess.Read,
filepath.Value.ToString());

try
{
permFileIO.Demand();
}
catch(Exception e)
{
}

This works but how do I catch an exception of the user not having the
right permissions to read the file?

Thanks
Sur

[Olaf Baeyens]

> My problem is that File.Exists works fine if my file is on my local

drive but returns false if its on any other drive. I think that the
issue is probably file permissions and so I have tried the following:

FileIOPermision permFileIO = new
FileIOPermission(FileIOPermissionAccess.Read,
filepath.Value.ToString());

try
{
permFileIO.Demand();
}
catch(Exception e) {
}

This works but how do I catch an exception of the user not having the
right permissions to read the file?

Replace the Exception to the exception you want to catch like this:

try {
permFileIO.Demand();
} catch(MyExceptionIWantToCatch e) {
// error
}

It might be that the program have no LAN or Internet access rights
(resposibility of the programmer), but also that the administrator on that
computer does not like the program to access the LAN or Internet drive. I
believe that this one is the one you need
System.Security.Policy.PolicyException

try {
permFileIO.Demand();
} catch(PolicyException e) {
// Report not enough user rights on this machine
}

Technically I believe in C# you might want to nest exceptions
try {
try {
permFileIO.Demand();
} catch(PolicyException e) {
// Report not enough user rights on this machine
}
}catch(Exception e) {
// Typical exception error reporting
}
}

But you might also use like this fall-through way of doing it:
If the exception was PolicyException then the second part is not executed.
But if it was not PolicyException then Exception is executed

try {
try {
permFileIO.Demand();
} catch(PolicyException e) {
// Report not enough user rights on this machine
} catch(Exception e) {
// Typical exception error reporting
}
}

(I hope I wrote it correctly)

[Willy Denoyette [MVP]]

"sur" <su************@hotmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Hello,

My problem is that File.Exists works fine if my file is on my local
drive but returns false if its on any other drive. I think that the
issue is probably file permissions and so I have tried the following:

FileIOPermision permFileIO = new
FileIOPermission(FileIOPermissionAccess.Read,
filepath.Value.ToString());

try
{
permFileIO.Demand();
}
catch(Exception e)
{
}

This works but how do I catch an exception of the user not having the
right permissions to read the file?

Thanks
Sur

You are confusing (and so does Olaf), Windows security and Code Access
Security, your problem is related to the first, that is, the USER running
the code has no permissions to access the resource (network share/file).
Access to a network share is controlled by the Windows security system
(through the USER's access token) and as such is a Windows security issue.
FileIOPermission is a CAS permission, here it's the CLR's security system
that checks whether the CODE has been granted FileIO permissions. While both
are totally different, they complement each other, so now you can have 'Code
access' and 'User access' control to a resource.

Willy.

[Olaf Baeyens]

> You are confusing (and so does Olaf), Windows security and Code Access

Security, your problem is related to the first, that is, the USER running
the code has no permissions to access the resource (network share/file).
Access to a network share is controlled by the Windows security system
(through the USER's access token) and as such is a Windows security issue.
FileIOPermission is a CAS permission, here it's the CLR's security system
that checks whether the CODE has been granted FileIO permissions. While both are totally different, they complement each other, so now you can have 'Code access' and 'User access' control to a resource.

I was talking about the .NET administrator that does not give LAN rights to
let the .NET program access the network folder.
Of course you also have to take into account that a Shared folder must have
enough share access rights and that the file/folder permissions on that
machine are set in such a way that you could read that folder.

I was assuming that his windows permissions and share rights were ok,
because that is the first to check maybe by opening the file with notepad.

We have 4 locations that could give the problem:
1. The file/folder have not enough Windows permission.
-> administrator of the shared machine
2. The file/folder share have not enoygh permission.
-> administrator of the shared machine
3. The programmer compiling the managed program forgot to tell the program
that
is should be able to access shared LAN folders.
4. The Administrator of the machine the program must run on should give the
manage
programs rights to go and look for a shared LAN folder.

Most programmers fail point 3 and 4 since they do not know that these are
new for them and should be taken into account.

Since in his code sample he is trying to dynamically demand read access, and
he gets an exception, that would suggest that the program running on that
have no rights to access a shared LAN driver, so it is up to the
administrator on that running machine to tell the .NET CLI is to be trusted
and is allowed to have access. Default it is turned off, so this explain's
why it works locally but not remotely.

But I admit it is sometimes confusing to understand tihis all.

[Willy Denoyette [MVP]]

"Olaf Baeyens" <ol**********@skyscan.be> wrote in message
news:43***********************@news.skynet.be...

You are confusing (and so does Olaf), Windows security and Code Access
Security, your problem is related to the first, that is, the USER running
the code has no permissions to access the resource (network share/file).
Access to a network share is controlled by the Windows security system
(through the USER's access token) and as such is a Windows security
issue.
FileIOPermission is a CAS permission, here it's the CLR's security system
that checks whether the CODE has been granted FileIO permissions. While

both

are totally different, they complement each other, so now you can have

'Code

access' and 'User access' control to a resource.

I was talking about the .NET administrator that does not give LAN rights
to
let the .NET program access the network folder.
Of course you also have to take into account that a Shared folder must
have
enough share access rights and that the file/folder permissions on that
machine are set in such a way that you could read that folder.

I was assuming that his windows permissions and share rights were ok,
because that is the first to check maybe by opening the file with notepad.

We have 4 locations that could give the problem:
1. The file/folder have not enough Windows permission.
-> administrator of the shared machine
2. The file/folder share have not enoygh permission.
-> administrator of the shared machine
3. The programmer compiling the managed program forgot to tell the program
that
is should be able to access shared LAN folders.
4. The Administrator of the machine the program must run on should give
the
manage
programs rights to go and look for a shared LAN folder.

Most programmers fail point 3 and 4 since they do not know that these are
new for them and should be taken into account.

Since in his code sample he is trying to dynamically demand read access,
and
he gets an exception, that would suggest that the program running on that
have no rights to access a shared LAN driver, so it is up to the
administrator on that running machine to tell the .NET CLI is to be
trusted
and is allowed to have access. Default it is turned off, so this explain's
why it works locally but not remotely.

But I admit it is sometimes confusing to understand tihis all.

No, a program that is loaded from a local drive runs at "full trust" by
default. That means that the "code" already runs with FileIOPermission no
matter the location of the file, the CAS security doesn't care about the
location, unless the OP explicitly denied access to the remote file or
directory, something I guess he didn't do.
That is why the OP's program succeeds when executing File.Exists for a local
file, but the reason why it fails to access a file on a shared drive is
because the "user" has no access to the shared resource.
Note that the OP got "the exception" before he added the code he posted, but
unfortunately failed to post the exception message, something that leads to
more confusion and endless discussion.

Willy.

[Olaf Baeyens]

> No, a program that is loaded from a local drive runs at "full trust" by

default. That means that the "code" already runs with FileIOPermission no
matter the location of the file, the CAS security doesn't care about the
location, unless the OP explicitly denied access to the remote file or
directory, something I guess he didn't do.

Odd, if I understand your argument, then it means that if I start up a .NET
program locally on my C: drive then CLI does not prevents me from accessing
a shared network file by default way?
I mean suppose, take a default Windows installation, create a default C#
form with a button to open a file, and it will, without protest open a
shared file when I start up the program on my C: drive?

Either something changed between .NET v1.0 to v1.1 or my tests here are
wrong, since it took me the hell of a time to find out how to make an
installer that automatically makes my program, installed locally to open a
shared folder witout complaint.

Maybe we are talking about the same thing here but somehow have a
communication problem.
Here my last try:

The program have the programmers .NET *permission* to open a shared folder
file, but the administrator of that local machine might have a .NET *policy*
not to let that program do that.
And I was always convinced that the default .NET installation has it's
*policy* never to allow a .NET program, even run locally have access t a
shared network folder/file by default.
You must activate this exceptional *policy* access by telling the .NET
framework to let the program with this key signature and maybe including
this version info to grant access to open a shared folder/file.
through this: "Control panel->Administrative Tools->Microsoft .NET Framework
1.1 Wizards->Trust an assembly"

Changing the global default trust is not a wise choice.

But since this is a scary thing for most users, this could be done
automatically through a setup project which is a pure unmanaged program, and
have thus rights to access the using a custom installer inherited from
System.Configuration.Install.Installer

[RunInstaller(true)]
public class Installer1 : System.Configuration.Install.Installer {
...
}

Willy were we talking about the same thing?
Or am I completely and officially confused? ;-)

I agree with you, it could be plain old Windows network access rights, but
my bet is on the .NET policy thing since this is new and newbie programmers
all fall for this one.

[Jon Skeet [C# MVP]]

Olaf Baeyens wrote:

No, a program that is loaded from a local drive runs at "full trust" by
default. That means that the "code" already runs with FileIOPermission no
matter the location of the file, the CAS security doesn't care about the
location, unless the OP explicitly denied access to the remote file or
directory, something I guess he didn't do.

Odd, if I understand your argument, then it means that if I start up a .NET
program locally on my C: drive then CLI does not prevents me from accessing
a shared network file by default way?
I mean suppose, take a default Windows installation, create a default C#
form with a button to open a file, and it will, without protest open a
shared file when I start up the program on my C: drive?

That certainly seems to work for me - I've just tried it.

Jon

[Olaf Baeyens]

> > Odd, if I understand your argument, then it means that if I start up a
..NET

program locally on my C: drive then CLI does not prevents me from accessing a shared network file by default way?
I mean suppose, take a default Windows installation, create a default C#
form with a button to open a file, and it will, without protest open a
shared file when I start up the program on my C: drive?

That certainly seems to work for me - I've just tried it.

Interesting I will have to test this again when I find time.
It could simplify the install procedure even more.

I assume we are using .NET framework v1.1?

[Olaf Baeyens]

> > > I mean suppose, take a default Windows installation, create a default
C#

form with a button to open a file, and it will, without protest open a
shared file when I start up the program on my C: drive?

That certainly seems to work for me - I've just tried it.

Interesting I will have to test this again when I find time.
It could simplify the install procedure even more.

I assume we are using .NET framework v1.1?

I just checked, and to my big supprise the pure C# program even executes
from a shared drive.
But it refuses to open a shared folder.

When I copy this test program locally then it starts up and to my suprise it
also opens the shared folder.

I am 100% sure that this did not happen 2 years ago when I was testing with
VC# 2002 and the .NET framework v1.0.
What changed?

Very curious. 8-)
Anyway, I am glad that it works like this, so distribution is now even
simpler :-)

[Willy Denoyette [MVP]]

"Olaf Baeyens" <ol**********@skyscan.be> wrote in message
news:43*********************@news.skynet.be...

> > I mean suppose, take a default Windows installation, create a default C# > > form with a button to open a file, and it will, without protest open
> > a
> > shared file when I start up the program on my C: drive?
>
> That certainly seems to work for me - I've just tried it.
>

Interesting I will have to test this again when I find time.
It could simplify the install procedure even more.

I assume we are using .NET framework v1.1?

I just checked, and to my big supprise the pure C# program even executes
from a shared drive.
But it refuses to open a shared folder.

When I copy this test program locally then it starts up and to my suprise
it
also opens the shared folder.

I am 100% sure that this did not happen 2 years ago when I was testing
with
VC# 2002 and the .NET framework v1.0.
What changed?

Very curious. 8-)
Anyway, I am glad that it works like this, so distribution is now even
simpler :-)

AFAIK it has always been like this, it's quite simple, or the code has
FileIOPermission or it doesn't. The CLR security system has no idea what a
shared resource is, there is no way to make the distinction at the
application level , it's only the OS that knows that a file is not local and
needs the help of the Filesystem redirector to access the file over the
network.

Willy.

[Olaf Baeyens]

AFAIK it has always been like this, it's quite simple, or the code has
FileIOPermission or it doesn't. The CLR security system has no idea what a
shared resource is, there is no way to make the distinction at the
application level , it's only the OS that knows that a file is not local and needs the help of the Filesystem redirector to access the file over the
network.

Odd, I guess that I have been testing by executing from a shared folder and
somehow got convinced that this was also the case when copied locally.
Well I learned a lot more now. :-)

[sherif talaat]

*** Sent via Developersdex http://www.developersdex.com ***