Michael, Yes you can have access to write without delete, I've had this happen before. You can also create without the permission to edit. eg, web.config in inetpub.
I'm not sure I'd consider that a hack. It certainly simplifies the process immensely but you could also use it as a kind of transaction. ie, create the temp file early, write your document to the temp file when you're ready, and then rename if successful. Who knows if the shared drive runs out of space or you lose network connectivity. Better to have a useless temp file than a misleading document file that is actually corrupt. Don't forget to record the temp file name or somehow scope it (eg to user or app instance) so you can clean up later if necessary. Finally, if all else fail, you could always write to a local "cache" or "recovery" folder to try again later when the network issues are resolved. Kind of like the MS Word document recovery prompt. Just some thoughts. David "If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate!" -Zapp Brannigan, Futurama On Mon, Apr 2, 2012 at 15:02, Michael Minutillo <[email protected]> wrote: > Hi all, > > I have an application that communicates with a document management system. > In the case where the DMS is down the app should store files in a > configurable network share. In order for this to happen all users to the > system should have write access to the network share. In order to prevent > the user from going through a heap of work only to discover that they can't > store documents in the share (if the DMS is down) I want to check if the > user can write to the folder when the application starts up and notify the > user if there is a problem. Is there a simple way to do this check? > > All of the solutions that I have found seem to suggest that you either have > to: > > (1) load the permission set for the folder and iterate through it by hand to > see if you are explicitly allowed/denied > OR > (2) you should just try and write and catch any exceptions. If you did write > it, delete it again > > The first is more complicated than I had hoped. The second is really a hack > but it's the leading contender at the moment. If I were to implement the > second approach is there a danger that the user will write a file > successfully to the share but not have the permissions to delete it? > > If anyone knows of a simpler method (or a good library) that will handle > this it would appreciated. I realize that even if the user can write to the > folder at app startup there is no guarantee that they'll be able to later > but there are operations that we don't even want to start if the user can't > write to the folder > > Regards, > > Michael M. Minutillo > Indiscriminate Information Sponge > http://codermike.com
