Hi Shawn, > The same goes for the "search.htm" file - it *should* go > under either the user appdata directory or the all users > appdata directory. > > All related resources (everything from js to css to htm > files) should also be moved over. Really, the only thing in > DQSD that would need to stay under program files is the dll > itself and the uninstall stuff. Everything else would be > migrated to the appdata folders.
Why? It's basically executable code. As long as the files aren't written to, I think we should be safe in putting them in %PROGRAMFILES%. Are you saying there are configurations in which %PROGRAMFILES% isn't even read-only, but execute-only? My take on this whole thing would be to reorganize like this: File category Location Expected ACL ------------------------------------------------------------- prefs/writable files %APPDATA% R/W localsearches %APPDATA% R/W executable/scripts %PROGRAMFILES% R/E searches %PROGRAMFILES% R/E On-demand-installed searches should be put into localsearches, all others are shared. Alternatively, we could put all searches into %APPDATA% except for the core searches (gg.xml, alarm.xml, etc). I'm working under the assumption that %PROGRAMFILES% is always readable here, but this seems reasonable. Does removing read access and running Office work? Kim ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ DQSD-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dqsd-devel
