Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Suggestions
➜ application manifest issues, comments?
|
application manifest issues, comments?
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Fiendish
USA (2,558 posts) Bio
Global Moderator |
| Date
| Sun 17 Feb 2013 (UTC) Amended on Sun 17 Feb 2013 12:01 AM (UTC) by Fiendish
|
| Message
| short version:
Are there undesired consequences of adding the necessary options to disable file virtualization (a UAC "feature") to an embedded application manifest?
( see http://www.codeguru.com/csharp/csharp/cs_misc/designtechniques/article.php/c15455/Tip-To-Disable-Virtualization.htm )
In Windows Vista, 7, and 8, an external manifest file can apparently be ignored for various seemingly arbitrary reasons.
long version:
The Aardwolf version of the GMCP mapper plugin (the one included in the Aardwolf MUSHclient package) includes a feature to perform regular integrity checks and backups of the sqlite database.
Occasionally the following scenario occurs (two accounts of this have been reported to me thus far)...
Someone on Windows 7 or 8 will experience file corruption and try to scrap their MUSHclient directory and start over. Erasing the MUSHclient directory, which they have invariably placed somewhere protected by UAC security, has the undesired result of leaving behind their old corrupted database files in the secret VirtualStore at %LOCALAPPDATA%\VirtualStore\Program Files\MUSHclient because Windows Vista+ by default virtualizes all file writes in secured areas to user-specific storage. And it, kind of stupidly at this point, does _not_ delete the virtual store when the MUSHclient folder is removed or overwritten.
So what happens, apparently, is that the next time MUSHclient loads, it accesses the old, corrupted files again, because those files exist in the virtual store.
So I got a report that this happened to a second user this morning, and I started to investigate options. As far as I can tell, my options are as follows:
1) Make sure that users never put the MUSHclient folder into a UAC protected space like Program Files
2) Construct an installer or other special program that deletes the virtual store.
3) Provide information on how to delete the virtual store in the event that the above scenario occuring again to another user
4) Block file virtualization entirely using the application manifest
Obviously (1) is impossible to enforce, and (2) limits directory portability.
I'm adding (3) to my website already, but I wanted to go further and just prevent the problem.
So I tried to create a manifest for MUSHclient.exe that would disable file virtualization. I followed a bunch of instruction pages and called it MUSHclient.exe.manifest and put it into the MUSHclient folder. But it wasn't working. Apparently external file manifests can be ignored for all kinds of reasons. So in order for this to work I think it would have to be embedded in the executable.
Thoughts? |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Sun 17 Feb 2013 12:16 AM (UTC) |
| Message
| | Stepping back to the real problem (the file corruption) is there a way of detecting that? For example, a SQLite3 integrity check done before you try to do the "real work". |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Fiendish
USA (2,558 posts) Bio
Global Moderator |
| Date
| Reply #2 on Sun 17 Feb 2013 02:18 AM (UTC) Amended on Sun 17 Feb 2013 02:24 AM (UTC) by Fiendish
|
| Message
| | I do periodic integrity checks already as stated. The question then becomes how one restores from a backup after detecting db corruption. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Sun 17 Feb 2013 03:10 AM (UTC) |
| Message
| | I must be missing an important step here. If you detect corruption, you delete and re-create the database file (from within the app). If virtualization puts the file somewhere else, so be it. Then you restore from the backup. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Fiendish
USA (2,558 posts) Bio
Global Moderator |
| Date
| Reply #4 on Sun 17 Feb 2013 04:22 PM (UTC) Amended on Sun 17 Feb 2013 04:25 PM (UTC) by Fiendish
|
| Message
| Well, at the moment I leave restoring from backups up to the user (manually, outside of the app). I am considering the possibility of doing this automatically within the app, but in any case let's imagine for a moment that there are no valid backups yet or that the backups have been deleted by the user or whatever other thing can happen.
In the event that the user attempts to replace the directory with a brand new download, they will seemingly find, to much surprise, that the old files are still there supplanting the new ones. I'm not sure exactly the conditions that cause this to happen, but I have seen it occur. The problem appears to be that the VirtualStore is not erased when the original files are. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #5 on Sun 17 Feb 2013 07:48 PM (UTC) |
| Message
| <sigh>
Windows, eh?
You have a file, it is in the directory where you want it, that being the directory that the app plans to use, but Windows chooses to use a different file.
Can you work around this by doing things the Windows way? For example, the mapper database, don't put it anywhere near where the MUSHclient.exe file is. Make sure you open/write/read to it in a supported directory, like My Documents. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Fiendish
USA (2,558 posts) Bio
Global Moderator |
| Date
| Reply #6 on Sun 17 Feb 2013 09:09 PM (UTC) Amended on Sun 17 Feb 2013 09:12 PM (UTC) by Fiendish
|
| Message
|
Quote:
<sigh>
Windows, eh?
Agreed. Keeping the old VirtualStore around after the directory is removed or replaced is so dumb it defies description.
Quote:
For example, the mapper database, don't put it anywhere near where the MUSHclient.exe file is. Make sure you open/write/read to it in a supported directory, like My Documents.
This is something I'm not readily willing to do without some serious thought, because people have a pretty strong expectation that the MUSHclient folder is self-contained. A number of Aardwolf players use things like USB keys and Dropbox for portability.
I am planning now to try to restore from backups automatically. With any luck that will further reduce the cases of this particular scenario. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #7 on Mon 18 Feb 2013 01:21 AM (UTC) |
| Message
|
Fiendish said:
This is something I'm not readily willing to do without some serious thought, because people have a pretty strong expectation that the MUSHclient folder is self-contained. A number of Aardwolf players use things like USB keys and Dropbox for portability.
That's exactly why it was done that way in the first place. The whole app was self-contained.
Now Windows throws a spanner in the works by silently redirecting files away from where they appear to be.
I can understand why, in a way. I was gobsmacked when I found out that under (earlier) Windows versions you could read/write to the Program Files folders as if they were just straight data. That fails in so many ways it is hard to describe. And this was after reading about how Windows had ACLs, permissions, blah, blah. But then they let programs, in the normal course of execution, store their data in Program Files.
However, it worked in the sense that it kept everything together. So I wasn't in a big hurry to split things up into some other (what?) folder where it might be safe to put user data.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
22,847 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top