The DMS in question is TRIM. The rest of the app will need to handle exceptional circumstances for when things go bad we just want to cover the basic scenario of when the user first starts the app (especially for the very first time) that they can write to the folder. If they can't then something major and infrastructural has gone on and the user should not really continue with their work. We're expecting that basically no-one will ever see this message as it should be a really rare occurrence.
The process beyond going into the backup folder is outside the scope of this application (and it's manual) so it's not relevant where the meta-data goes/comes from. On Mon, Apr 2, 2012 at 1:29 PM, mike smith <[email protected]> wrote: > On Mon, Apr 2, 2012 at 3:02 PM, Michael Minutillo > <[email protected]> wrote: > > Hi all, > > > > I have an application that communicates with a document management > system. > > Which one? I've got a good reason for asking :) > > > 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? > > > > It's really more complicated than this. Network shares can go up and > down. User permissions can alter whilst the app is running..... > Admin could alter which users/groups can access it, quotas... > > > 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? > > > > You probably would want to set it so the user cannot delete (other > users files) which may leave the store as being write-only. Where's > the metadata from the edocument going to come from when the DMS comes > back up? > > > 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 > > > > -- > Meski > > http://courteous.ly/aAOZcv > > "Going to Starbucks for coffee is like going to prison for sex. Sure, > you'll get it, but it's going to be rough" - Adam Hills >
