Re: Tell Me Where To Stick It!

Tech-Archive recommends: Speed Up your PC by fixing your registry



Rick Raisley wrote:
Karl Peterson posted the following useful link:

Visual Studio Magazine Online | Classic VB Corner: Lemme Tell Ya Where To
Stick It
http://visualstudiomagazine.com/columns/article.aspx?editorialsid=2962

Appreciated.

but for me, that didn't quite cut it. And rather than ask my specifics onto
another's thread and muck it up, I thought I'd start my own. I have two
basic types of apps I'd like advice on the location of files for:

Maybe what wasn't stressed strongly enough was the very first fork? That column was
specifically targetted at *application* data -- that used directly by the
application itself. Not user data. So for every datafile you need to generate,
that's the first question to ask -- is this a *user* file or is it one only the app
will need? If you answer "both" then you need to refine your storage breakdown to
meet this distinction.

WORK PROGRAM
I have a program for work that constantly updates the program itself, from
the network, updates INI files depending on server and user location, and
creates and deletes many local files to speed things up. The starter program
(which the installed shortcut points to) itself goes there as well. Most of
these files should be available to any user logging in to the PC, as they
determine the operation of it.

After a fair amount of fooling around, I ended up putting everything above
into a single folder, CSIDL_COMMON_APPDATA, or as it often resolves to:

C:\Documents and Settings\%USERNAME%\Local Settings\Application Data or
C:\Documents and Settings\All Users\Application Data for Vista

Now, for work, that works great. I think it's a good setup. Although reading
the above article, it is not writable by ordinary users (I think our company
only uses Power Users). So where would be the best alternate location? In
this case, the user does /not/ normally need to browse to the folder. He
just needs to be able to always /write/ to the folder.

CSIDL_COMMON_APPDATA is analagous to HKEY_LOCAL_MACHINE. It's not a place you want
"ordinary" users making decisions for one another. This is where you'd store
information that dictates how the application will run for *all* users.

What you describe sounds a lot like *user* data, albeit shared. In this case, the
"appropriate" (and I'm always one to use that word with caution!) location would be
CSIDL_COMMON_DOCUMENTS.

OTOH, if this is a corporate setting, where you *own* and administer the hardware,
you get to put this stuff whereever you feel it works best for you! That's the
beauty of writing in-house tools. :-)

MARKETED PROGRAMS
I have a series of programs which I market, and which are related to each
other. They use many of the same data files for program operation. They each
use many thousands of data files. While individual user preferences could
easily be saved in the user's profile (C:\WINNT\Profiles\%USERNAME%\Local
Settings\Application Data), I certainly don't want over 5,000 data files to
be. And they shouldn't be in the My Documents folder, which would prevent
operation of the program by any other user. So, these data files are a
problem for location. Basically, other than my program, I need to store the
following files, WHICH WILL ALL CHANGE:

1) Data files, organized separately for each program. Thousands of them.
Need to be available to all users, and easily browsed to and reorganized
using Explorer. People make their own versions, zip them up, reorganize by
directories, add zips of new ones sent to them by others, etc. Where to
locate them?

User configurable, with CSIDL_COMMON_DOCUMENTS\YourApp as the default. I'd advise
the "configuration" be done once at installation, and then only by an admin edit of
an INI file in CSIDL_COMMON_APPDATA\YourApp if it needs to change later.

2) Common data files, customized by the program or sent among users, these
are used by all the programs. Again, one user will send another several
files that he uses, and the user needs to be able to save them from an email
to a specific LOGICAL directory location, where the programs will pick up on
them and use them.

Same as above. Except perhaps allowing the user to "open" any given folder that
contains the requisite folder/file structure. Definitely default to a location off
CSIDL_COMMON_APPDATA.
--
..NET: It's About Trust!
http://vfred.mvps.org


.



Relevant Pages

  • Tell Me Where To Stick It!
    ... the user does /not/ normally need to browse to the folder. ... They use many of the same data files for program operation. ... Common Files - read only after install ... EASILY browse to, reorganize, copy files received in emails to, etc? ...
    (microsoft.public.vb.general.discussion)
  • Re: Virtualization
    ... One for the Common folder and one for User. ... I try in most cases to let me application create data files as needed, ... at install time, I install those files in the common data area. ...
    (microsoft.public.vb.general.discussion)
  • Re: Relative Links with includeText
    ... INCLUDETEXT, INCLUDEPICTURE and LINK don't support relative links. ... A generic master Document that pulls in additional data specific ... based upon the folder it is in. ... create the data files; I store those data files in separate folders. ...
    (microsoft.public.word.docmanagement)
  • Re: Installing data files with application?
    ... If the user is allowed to "Rename" the data files, then they should be put in his/her "My Documents" folder. ... If they are put in the "My Documents" folder then they probably should NOT be uninstalled when your app uninstalls... ... All is well until the user changes the name of the> file (I ... > re-install this file if deleted" setting in the installer part of VS ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Owners and My Documents folders
    ... Will removing files from one folder, say Owner's Documents, ... Purchase an external hard drive. ... Copy data files (music, pictures, ... your system and do incremental backups. ...
    (microsoft.public.windowsxp.basics)