Knowing the User's Rights

[ImDaFrEaK]

I am not sure if this is the correct place to put this but I am hoping to learn how to know the users rights before attempting to have them write to files.

In my program, I want the user to be able to alter certain audio files. On the Admin side this works fine but when testing on my wifes side of the computer, non-admin, I can't alter the file. I get an error saying "Access to Path" the file name and path "is denied." Before attempting to Re-Write information on particular files I would like to know the priveldges. As of right now I am stuck using a Try Catch and I prefer not to if there is a correct method.

 

[ImDaFrEaK]

Never Mind....

Never mind for now. I have reviewed the forum in detail and apparently many people have had this problem. This thread isn't new to this forum and I apologize for adding it again. There are quite a few other threads that ask this very question. As it appears I have no choice but to use a Try Catch statement unless I have read something wrong. If anyone does have any new information on this I'm still all ears but for now looks like "Try Catch" is the only answer.....

 

[cjard]

try/catch is the usual way of dealing with an exception, and an exception is anything that prevents you from proceeding on a normal course.. so this is one of those cases, i think, where you try the edit, and catch it if it fails - its ok to have exception handling for this rather than a "i'll work out in advance if i have admin rights to the file and then decide whether or not t edit"

the other thing youll find here, is that there may be more reasons why you cant edit a file, such as open/locked, security permissions on .net, windows security permits etc..
exception handling lets you deal with all these in one go without having to think ahead of every possibility

additionally, heres some more info on try/catch:


i use exceptions to pass messages back to the calling method in case of unusual events.. suppose the user wants to search and when i look at the search parameters they are likely to returna huge number of results. at that point I ask the user "this is a huge result set, do you really want to run the search?" and give them 3 options, yes/no/cancel - cancel exits the search screen, no lets then go back to the search screen and type something, and yes runs the search

i defined 2 custom exceptions for this:
SearchStoppedException
SearchExitedException

if the user clicks npo, i throw the stopped one
if they click cancel, i throw the exited

in the method that calls search (because in my app,there may be tens or hundreds of search screens) i write:

Try
  DoSearch() 'throws exceptions
Catch ex as SearchStoppedException
  'Do code here to handle the user stopping the search but not exiting searchmode
Catch ex as SearchExitedException
  'Do code here to leave search mode completely
Catch ex As Exception
  MessageBox.Show("Some error occurred, report this to the developer: " & ex.Message)
End Try

now any screen can use my search and handle the aborts in their own way

This is why exception handling is a good way to go.. you can choose in your case to catch a SecurityPermission and say tot he user "you dont have acess", and you can catch a FileIOException (or whatever) and say "system has a problem reading the file"

etc..