RichTextBox saves files in wrong place

[mick]

I have a small app that contains a RichTextBox which will save its contents
to the apps folder and load it whenever the RTB opens again - at least
that is what is supposed to happen and in fact used to happen.

here is the RTB window load event. It either gets the previously stored

save directory if it exists else the current dir.

private void TextBoxForm_Load(object sender, EventArgs e)

{

if (Properties.Settings.Default.settingsSaveDirectory.Length != 0)

_saveDirectory = Properties.Settings.Default.settingsSaveDirectory;

else

{

Properties.Settings.Default.settingsSaveDirectory
=Directory.GetCurrentDirectory();

Properties.Settings.Default.Save();

}

if (Properties.Settings.Default.settingsDebug) MessageBox.Show("At
TextBoxForm_Load() the save dir is \n" + _saveDirectory);

}

Now I`ve stepped through the code and added a MessageBox at the end to check
what the save dir is and at all points

it`s C:\Program Files\DiskInfo which is as it should be. However it isnt
saving the file there but at

C:\Users\mk\AppData\Local\VirtualStore\Program Files\DiskInfo. Anyone know
why that would be?

The block of code that loads the file is simply

var s = _saveDirectory + "\\" + _fileName;
try
{
if (File.Exists(s))
richTextBox1.LoadFile(s);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
if (Properties.Settings.Default.settingsDebug)
MessageBox.Show("At TextBoxForm Creation the save path is \n" + s);

mick

 

[Jeff Gaines]

it`s C:\Program Files\DiskInfo which is as it should be. However it isnt
saving the file there but at

C:\Users\mk\AppData\Local\VirtualStore\Program Files\DiskInfo. Anyone know
why that would be?

Have you recently moved from XP to Vista or Win7?
Both apply the rules strictly, users can't write to Program Files.
You should use
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); to
get a path the user can write to.

 

[Konrad Neitzel]

Hi!

Have you recently moved from XP to Vista or Win7?
Both apply the rules strictly, users can't write to Program Files.
You should use
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); to
get a path the user can write to.

Another possible way could be the IsolatedStorage class:
http://msdn.microsoft.com/en-us/library/system.io.isolatedstorage.isolatedstorage.aspx

With kind regards,

Konrad

 

[Peter Duniho]

[...]
Now I`ve stepped through the code and added a MessageBox at the end to
check what the save dir is and at all points

it`s C:\Program Files\DiskInfo which is as it should be. However it isnt
saving the file there but at

C:\Users\mk\AppData\Local\VirtualStore\Program Files\DiskInfo. Anyone
know why that would be?

Yes. You are running your program on Vista or Windows 7, which are both
much stricter about managing access rights, and virtualize sensitive
directories, such as those found under the Program Files directory.

Your program shouldn't be using Program Files as a repository. It's
hard to know for sure what place is more appropriate for your data
without more details, but you can use the Environment.GetFolderPath()
method to obtain paths for various special folders on the system.

For user-specific data that should be private to the application, the
ApplicationData folder or LocalApplicationData folder is a good choice.
For user-specific data that is intended to be the usable output (e.g.
a document) of the application, the MyDocuments folder is good.

Note that in general, data that is intended to be shared among users
should be read-only. The appropriate location would be
CommonApplicationData, but data there should be initialized only during
setup or via some administration tool. Normal users won't have write
access to the folder.

Pete

 

[mick]

Have you recently moved from XP to Vista or Win7?
Both apply the rules strictly, users can't write to Program Files.
You should use
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); to
get a path the user can write to.

I had actually implemented an option for the user to choose where to store
the text file. This option seems a bit redundant now if they cant actually
choose. Whilst
I knew there were restrictions on saving to Program Files I didnt realise
that an app
couldnt save to its own folder.

I`m using Win 7 so I`m at a bit of a loss how this used to work. Ive even
got old
RTB text files saved in the apps folder, they are just being ignored now.
I`m wondering if I have altered the permissions on the folder in the past.
Dont know.
Anyway thanks to everyone for replying.

mick

 

[mick]

Hi!



Another possible way could be the IsolatedStorage class:
http://msdn.microsoft.com/en-us/library/system.io.isolatedstorage.isolatedstorage.aspx

Never come across this before I`d need to look into what it is and does. The
msdn site doesn`t
reveal an awful lot. It seems to assume you already know

mick

 

[mick]

[...]
Now I`ve stepped through the code and added a MessageBox at the end to
check what the save dir is and at all points

it`s C:\Program Files\DiskInfo which is as it should be. However it isnt
saving the file there but at

C:\Users\mk\AppData\Local\VirtualStore\Program Files\DiskInfo. Anyone
know why that would be?

Yes. You are running your program on Vista or Windows 7, which are both
much stricter about managing access rights, and virtualize sensitive
directories, such as those found under the Program Files directory.

Your program shouldn't be using Program Files as a repository. It's hard
to know for sure what place is more appropriate for your data without more
details, but you can use the Environment.GetFolderPath() method to obtain
paths for various special folders on the system.

As I said in another post I had implemented it as a user option with the
default
set to the apps own folder. I would have thought there would have been some
sort
of flagging if the saves were being redirected. It`s no big deal though, I
can take out
the "Save to" option.

For user-specific data that should be private to the application, the
ApplicationData folder or LocalApplicationData folder is a good choice.
For user-specific data that is intended to be the usable output (e.g. a
document) of the application, the MyDocuments folder is good.

Yes I think I`ll settle for the AppData route.

Thanks again,

mick

 

[Peter Duniho]

[...] I would have thought there would have been
some sort of flagging if the saves were being redirected.

I have no idea what that you mean by that – "some sort of flagging" –
but obviously whatever you thought would happen, doesn't.

 

[mick]

[...] I would have thought there would have been
some sort of flagging if the saves were being redirected.

I have no idea what that you mean by that – "some sort of flagging" – but
obviously whatever you thought would happen, doesn't.

Some sort of indication that the file isnt being saved or cant be saved
at the selected location. Anyway, no matter.

mick

 

[Peter Duniho]

[...] I would have thought there would have been
some sort of flagging if the saves were being redirected.

I have no idea what that you mean by that – "some sort of flagging" –
but obviously whatever you thought would happen, doesn't.

Some sort of indication that the file isnt being saved or cant be saved
at the selected location. Anyway, no matter.

That's the whole point of virtualization. The file location is
_virtual_, and so it _can_ be saved at the location your program indicates.

The location your program see just happens to be somewhere different on
the _actual_ file system.

It's just like virtual addresses. When your program has a pointer to
memory, that pointer isn't to the actual physical memory. It's to a
virtual address, mapped by the OS and hardware to a specific physical
memory address that's completely different.

Same thing for your file.

Pete

 

[Jeff Gaines]

I had actually implemented an option for the user to choose where to store
the text file. This option seems a bit redundant now if they cant actually
choose. Whilst
I knew there were restrictions on saving to Program Files I didnt realise
that an app
couldnt save to its own folder.

Users can chose, but they have to chose within some constraints. You could
write your own file save dialog which returned messages to the user if
he/she makes a choice Windows can't live with.

 

[Konrad Neitzel]

Hi Mick!

Never come across this before I`d need to look into what it is and does.
The msdn site doesn`t
reveal an awful lot. It seems to assume you already know

I have to say: Sorry. The Link I gave you was simply not the correct one. I
always check first in my local MSDN nd try to get the right page on the web
for a link afterwards. And I linked the IsolatedStorage Class instead of the
IsolatedStorageFile Class (which is the right and quick start to use
IsolatedStorage.)

This Isolated Storade is something, I saw the first time when I prepared
myself for the 70-536 exam. So far I only used it in some examples playing
around with.

The quick way to get started is the IsolatedStorageFile Class which gives
some nice and easy to use static Functions:
Get<Machine|User>StoreFor<Application|Assembly|Domain>
So you can decide, if it should be seperate per user or for the whole
machine and the second decision if it is Application, Assembly or Domain
specific.
Or directly use the GetStore Method and use the Flags from the
IsolatedStorageScope Enumeration. (This also has a nice Flag "Roaming" which
could be of interest if you operate in an environment that has roaming
profiles. But I had no proper test environment for that so I was unable to
play around with that.)

The big advantage I see is, that you get some storage that will not
interfere with any other applications that also want to read and write files
....

The correct link I wanted to give even in my first post is:
http://msdn.microsoft.com/de-de/library/system.io.isolatedstorage.isolatedstoragefile.aspx

With kind regards,

Konrad