make sure that folders and files created by application be fullaccessible to any user

[pamela fluente]

I have a winform application. Framework 4.0. ClickOnce security
enabled. Full trust application.
The application creates some folders and some files in the program
root directory.

On windows 7 (64 bit) the current user cannot see at all the folders
created by my application inside the program root directory (while
they are instead actually there).

How do i make sure they can see and freely edit these files currently
not accessible ?
[can i set some attributes of folders/files programmatically ? I dont
need to restrict
access: they could/should be accessible by anyone]

Thank you


-Pam

 

[pamela fluente]

I have a winform application. Framework 4.0. ClickOnce security
enabled. Full trust application.
The application creates some folders and some files in the program
root directory.

On windows 7 (64 bit) the current user cannot see at all the folders
created by my application inside the program root directory (while
they are instead actually there).

How do i make sure they can see and freely edit these files currently
not accessible ?
[can i set some attributes of folders/files programmatically ? I dont
need to restrict
access: they could/should be accessible by anyone]

Windows 7 has folders that are protected like Program Files and
Windows\System32. All data type files needed by program or accessible by
a user should be placed in the ProgramData folder. The ProgramData
folder is a hidden folder that you will have to unhide in order to see
the folder.

Or you can make a folder that is not in a protected folder and place the
files there too.

I am putting all in the program root folder:

Application.StartupPath

I need that anything i create in that folder be clearly visible and
editable to anyone.
Some of my users with win 7 64 bit cannot see the files and folders i
create
inside the program root folder.

[I don't need to touch any other folder. Only my own program folder]


-Pam

 

[pamela fluente]

I am putting all in the program root folder:

Application.StartupPath

I need that anything i create in that folder be clearly visible and
editable to anyone.  [...]

Then don't install your program in a restricted directory like under the
"Program Files" directory.

That directory is off-limits to non-admin users.  Period.  It is a bad
idea for you to write to the same directory in which the program is
installed regardless, never mind to expect users to be able to modify
files that are in that directory.  But if you insist on doing that, the
only correct way to do it is to install the program in a directory where
users already have write permissions.  For example, a directory under
the "Users\Public" directory.

It is actually very likely that it's a poor user-interface design choice
to create a file that multiple users are expected to have access to and
to modify (I can't say with certainty without knowing exactly the nature
of the program, but exceptions are exceedingly rare and I doubt your
program is one of them).  But assuming you really want to stick with
that approach, it would be much better to simply ask the users to choose
the location for the file (defaulting to a directory under
"Users\Public\Documents", specific to your application, and requiring
normal write permissions in any case) while leaving your program
installed in the usual place.

Pete

Yes Pete is a very transparent application which needs no security at
all. It must be fully accessible by anyone.

I Just store text files in its root folder, inside a folder. The
strange thing is that all my user (xp, win 7)
have absolutely no problem. Only with win 7 64 bit some of them are
not seeing the files.

Further, they are all administrators, and can see and access the
program root folder: Application.StartupPath
but they don't see the txt files and other folders i create inside it
(i dont set any attribute).


-Pam

 

[pamela fluente]

[...]  The strange thing is that all my user  (xp, win 7)
have absolutely no problem. Only with win 7 64 bit some of them are
not seeing the files.

Further, they are all administrators, and can see and access the
program root folder:  Application.StartupPath
but they don't see the txt files and other folders i create inside it
(i dont set any attribute).

Probably your program is installed as a 32-bit application and they are
looking in the wrong "Program Files" directory.

That doesn't change anything else that I wrote.  Your fundamental
approach is broken.

I have no doubt you'll completely ignore this advice, but it's important
for it to be posted in these newsgroups anyway, in the hopes that other
people don't make the same mistake you're making.

Pete

Not ignoring the advice. I am instead very grateful. Just wondering
about the reason.
(They made sure to look in the right directory, and still nothing.)

Back to the advice, i have seen in the list these:

Environment.SpecialFolder.MyDocuments()
Environment.SpecialFolder.CommonDocuments()

can you advice which one (or other one, in terms of code) is the best
choice. I will replace everywhere the
Application.StartupPath with the special folder you guys suggest.

(To me it's could also be fine that the user which runs the program
can see only the files created by his own work session
.... but it would probably be better anyone can see everything)


Thanks a lot

-Pam

 

[Armin Zingler]

Am 20.07.2011 16:28, schrieb pamela fluente:

Back to the advice, i have seen in the list these:

Environment.SpecialFolder.MyDocuments()
Environment.SpecialFolder.CommonDocuments()

Depends on whether it's application data or not. If it is, I store it
in ApplicationData or CommonApplicationData. (The latter if it's common
to all users.) It it's not application data, I use a sub folder in MyDocuments.
I don't see CommonDocuments here (FW 4.0?)

I consider "application data" the data that the user doesn't know about
or wouldn't know how to handle, e.g. an application options file; in opposite
to a word document that he explicitly works with.

BTW, the "program files" directory is never backed up because it could be
reinstalled in case. That's the reason why I wouldn't store data there.

 

[pamela fluente]

Am 20.07.2011 16:28, schrieb pamela fluente:



Depends on whether it's application data or not. If it is, I store it
in ApplicationData or CommonApplicationData. (The latter if it's common
to all users.) It it's not application data, I use a sub folder in MyDocuments.
I don't see CommonDocuments here (FW 4.0?)

I consider "application data" the data that the user doesn't know about
or wouldn't know how to handle, e.g. an application options file; in opposite
to a word document that he explicitly works with.

BTW, the "program files" directory is never backed up because it could be
reinstalled in case. That's the reason why I wouldn't store data there.

Well i just tried to open the c:\programdata folder and has a padlock
and i cant open even on my own computer!!

I need something VERY OPEN and accessible. Users have NOT to struggle
to find it.
My users are housewives! Must be SIMPLE!

Must be a click away and no protection whatsoever!

I am generating text files that anyone has to be able to read quickly!

What's the best choice given the above requirements (please provide
the name in actual code) ?


-Pam

 

[pamela fluente]

Given Armin's remark i probably would go for

Environment.SpecialFolder.CommonDocuments()

(if no different advice provided) although i am not even sure to what
actual directory it will map (?) ...

An even simpler location for my repository could be the desktop, but
probably that's way too invasive...

-Pam

 

[pamela fluente]

I always use:

Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Applicatio nData),
"My Application Name");

To ensure that it is not mixed together with other stuff the user
accidentally might delete.

To access the folder manually you have to open %APPDATA%/My Application Name

Thank you Bjørn very valuable suggestion!

and ... Thank you all guys ! I am going to revise my little app
according to your suggestions!

Very helpful.


-Pam