1

I'm writing a windows service that will have a 'LocalService' account type. I have a file that stores what it has to do.

I also have a windows form GUI where that file is also accessed to add/remove instances of the action for the service to perform. (dont know if its relavant but the service downloads tables from a webservice and exports them to any database the user has access to. these downloads are scheduled to happen regularly)

The service will only be installed on a user account.

I was planning on storing the file in user appdata folder however while debugging the service I got the error "Access to path [path] is denied"

Where would you recommend storing this file so it is accessible from both programs? Thanks

EDIT: Looking a bit more, I've realised that 

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)

finds a different path for the service and the windows form app.. And that that app cant access the service appdata just as the service cant seem to access user appdata. so the same question stands!

ANOTHER EDIT: So it turns out

Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)

is accessible from a local service and a user program - doh

...but some places seem to be read only...

user1711383
  • 778
  • 2
  • 11
  • 20
  • just to be explicit.... The service that accesses this data is running under a different id to the gui app, right? "Local system" versus ? The sentence "The service will only be installed on a user account" is confusing. – PeteH Oct 05 '12 at 14:51
  • Maybe the file system isn't the right place to store this (if multiple users need to keep their settings separate). If the GUI app talked directly to the service, and had the service maintain a single, pristine file (maintaining user isolation, etc), that may be a better model? – Damien_The_Unbeliever Oct 05 '12 at 14:52
  • @Pete local system indeed. sorry ive never written a windows service before. The service and the GUI are wrapped in the same installer... I guess that statement was incorrect. – user1711383 Oct 05 '12 at 15:07
  • @Damien_The_Unbeliever The program will not be used by more than a single user per machine. Multiple users is beyond the design spec. You might be on to something with the gui talking to the service but I wouldnt know where to start. I'll look into it. thanks – user1711383 Oct 05 '12 at 15:09

1 Answers1

0

Three options as I see it:

  • Run the service under the user's login id

Upside - both processes will have identical access to the various parts of the file system, so should remove your immediate problem

Downside - if the user changes their password the two will get out of sync.

  • write to some "neutral" part of the file system (or perhaps the registry) where shared access won't be a problem. The trouble with AppData is that as you've found, Windows sets up all kinds of protection around it in order to ringfence different users from each other.

Upside - no problems writing

Downside - you're effectively inventing your own standard. 15 years ago this would have been a no-brainer, the registry, but these days I get the impression that the registry is frowned upon (even though ms still rely on it!). If you do go down the registry route, make sure you're aiming at hklm not hkcu else you'll have the same problem!

  • During your setup, do some tricks to set up access to the relevant folders. But this is basically tearing down the protection that Windows sets up. Doesn't sound too sensible to me.
PeteH
  • 2,394
  • 1
  • 20
  • 29