A
Aotrs Commander
I am using Windows 10 home, updated as by current updates (28/08/2020).
I have a legacy program (from prior, pre-7 versions of Windows), HeavyMetalPro, which saves data to the Program Files (x86) folder. I had (inadvertently) not been running it is administration mode (apparently sometimes time bettwen my last using it, either when I cloned the drive or re-installed it, that setting was not maintained).
When I save data in normal mode, it is not actually saving data to the Program Files (x86) folder (and subfolders) as it says it is doing, as new files do not exist there in explorer (where can get at them to back them up). If I run it in adminiatration mode, it does not see these new files, nor any any changes to existing files.
Windows is clearly saving the data somewhere else. One person I have talked to so far believed that Windows was linking said files somewhere else and merely displaying it was saving them in that folder.
I have hidden files visible by default, and was unable to locate any obvious folders in User Data. I have attempted to speak to MS support chat about this issue, but they were monumentally unhelpful because of the ridiculous 1-minute timer and ended the chat while I was still doing what they told me to do last; the only potentially useful thing they did was to ensure that protected system folders are currently not hidden (I'll rehide that as soon as this issue has been dealt with). I also was in the middle of reporting that the files were not showing up in Quick Access when the chat was cut off.
Where, then, does Windows link and store data when it is called to save to Program Files (x86) by a program that is not being run in administation mode?
My problem is compounded by the fact search is functionally useless, due to the inability of the files system to tell the difference between the old drive (F:, now a back-up) and the cloned drive (C
- search simply doesn't look on C: drive. (Disconnecting F:, running a new search index and re-connecting F: which might fix that issue (maybe?) is beyond my technical abilities and, at the moment and with lockdown it is difficult to get my usual technical source to do that.)
Continue reading...
I have a legacy program (from prior, pre-7 versions of Windows), HeavyMetalPro, which saves data to the Program Files (x86) folder. I had (inadvertently) not been running it is administration mode (apparently sometimes time bettwen my last using it, either when I cloned the drive or re-installed it, that setting was not maintained).
When I save data in normal mode, it is not actually saving data to the Program Files (x86) folder (and subfolders) as it says it is doing, as new files do not exist there in explorer (where can get at them to back them up). If I run it in adminiatration mode, it does not see these new files, nor any any changes to existing files.
Windows is clearly saving the data somewhere else. One person I have talked to so far believed that Windows was linking said files somewhere else and merely displaying it was saving them in that folder.
I have hidden files visible by default, and was unable to locate any obvious folders in User Data. I have attempted to speak to MS support chat about this issue, but they were monumentally unhelpful because of the ridiculous 1-minute timer and ended the chat while I was still doing what they told me to do last; the only potentially useful thing they did was to ensure that protected system folders are currently not hidden (I'll rehide that as soon as this issue has been dealt with). I also was in the middle of reporting that the files were not showing up in Quick Access when the chat was cut off.
Where, then, does Windows link and store data when it is called to save to Program Files (x86) by a program that is not being run in administation mode?
My problem is compounded by the fact search is functionally useless, due to the inability of the files system to tell the difference between the old drive (F:, now a back-up) and the cloned drive (C
- search simply doesn't look on C: drive. (Disconnecting F:, running a new search index and re-connecting F: which might fix that issue (maybe?) is beyond my technical abilities and, at the moment and with lockdown it is difficult to get my usual technical source to do that.)Continue reading...