tags:

views:

88

answers:

5

-What is the most foolproof way of ensuring the folder or file I want to manipulate is accessible (not read-only)?

-I know I can use ACL to add/set entries (make the file/folder non-readonly), but how would I know if I need to use security permissions to ensure file access? Or can I just add this in as an extra measure and handle the exception/negative scenario?

-How do I know when to close or just flush a stream? For example, should I try to use the streams once in a method and then flush/close/dipose at the end? If I use dispose(), do I still need to call flush() and close() explicitly?

I ask this question because constantly ensuring a file is available is a core requirement but it is difficult to guarantee this, so some tips in the design of my code would be good.

Thanks

A: 

-What is the most foolproof way of ensuring the folder or file I want to manipulate is accessible (not read-only)?

Opening them in write-mode?

dirkgently
A: 
  • Try and write a new file into the folder and catch any exceptions. Along with that do the normally sanity checks like folder/files exists etc.

  • You should never change the folder security in code as the environment could drastically change and cause major headaches. Rather ensure that the security is well documented and configured before hand. ALternatively use impersonation in your own code to ensure you are always running the required code as a user with full permissions to the folder/file.

  • Never call Dispose() unless you have no other choice. You always flush before closing the file or when you want to commit the content of the stream to the file/disk. The choice of when to do it depends on the amount of data that needs to be written and the time involved in writing the data.

Diago
A: 

100% foolproof way to ensure a folder is writable - create a file, close it, verify it is there, then delete it. A little tedious, but you asked for foolproof =)

Your better bet, which covers your question about ACL, is to handle the various exceptions if you cannot write to a file.

Also, I always call Close explicitly unless I need to read from a file before I'm done writing it (in which case I call flush then close).

Jess
A: 
  • Flush() - Synchronizes the in-memory buffer with the disk. Call when you want to write the buffer to the disk but keep the file open for further use.
  • Dispose(bool) - Releases the unmanaged resource (i.e. the OS file handle) and, if passed true, also releases the managed resources.
  • Close() - Calls Dispose(true) on the object.

Also, Dispose flushes the data before closing the handle so there is no need to call flush explicitly (although it might be a good idea to be flushing frequently anyway, depending on the amount and type of data you're handling).

If you're doing relatively atomic operations to files and don't need a long-running handle, the "using" paradigm is useful to ensure you are handling files properly, e.g.:

using (StreamReader reader = new StreamReader("filepath"))
{
    // Do some stuff
} // CLR automagically handles flushing and releasing resources
Stuart Childs
Thanks. How do I decide between setting the bool for Dispose() as true or false? Thanks.
dotnetdev
I think most of the time you'll set it as true. If there was some situation where you needed to release an unmanaged resource (like a file handle) but still wanted to access the managed .NET object (which you'd have to be careful about), pass false. This is highly unlikely though and I'd avoid it.
Stuart Childs
If you're not doing anything non-standard you can stick Close(). If you're doing some really custom filesystem work, you should definitely read and reread the MSDN docs on "Cleaning Up Umanaged Resources" and the IDisposable interface. Maybe reread it again afterwards; it can be confusing. :)
Stuart Childs
+1  A: 

There is no way to guarantee access to a file. I know this isn't a popular response but it's 100% true. You can never guarantee access to a file even if you have an exclusive non-sharing open on a Win32 machine.

There are too many ways this can fail that you simply cannot control. The classic example is a file opened over the network. Open it any way you'd like with any account, I'll simply walk over and yank the network cable. This will kill your access to the file.

I'm not saying this to be mean or arrogant. I'm saying this to make sure that people understand that operating on the file system is a very dangerous operation. You must accept that the operation can and will fail. It's imperative that you have a fallback scenario for any operation that touches disk.

JaredPar
+1. While you should always be catching exceptions anyway, it's especially important with unmanaged resources like files. So many things can go wrong and .NET can't save you. Your users will appreciate proper error handling when their 2-hour network sync is interrupted by a cable getting yanked.
Stuart Childs