Xml file are saved in two different path - c++

I created application that store some data to XML file. The issues is with the path of the XML saving. Am using TinyXML to save the data in vc++.
When I deploy this application, it installs in "C:\Program files(x86)\applicationname " and when I run the application the XML file is saving in
"C:\Users\UserName\AppData\Local\VirtualStore\Program Files (x86)\ApplicationName ".
I have made this application to work on system startup. So when I restart this application,
the xml file is stored in different path "C:\Users\UserName\AppData\Local\VirtualStore\windows\sysWOW64"
I want my XML to be stored in the path where I installed or should be stored in appdata, application name
What should I do to store XML file in one places where application is installed?
doc.SaveFile( "test.xml" ); // xml saving code in tinyxml library

Firstly, this has nothing to do with C++, as the C++ code is probably working. Same with XML and tinyxml and even visual-c++.
It seems that windows redirects those write accesses to a user-specific "VirtualStore\Program Files", but I'll leave it to you to research the actual semantics of that. On startup, when there is no user, this path obviously differs, since the former user is not logged in.
Now, in order to get a fixed path, you can use the function GetModuleFileName() to find out the location of your executable and use that path to locate Smartmeter.xml. However, the problem you are facing now is that programs installed under "Program Files" don't magically gain write access rights to their install directory. This is to protect one user from messing with data of another user.
I think that what you are doing is writing a program that runs in the background, which would be called a "service" under MS Windows. What is still unclear is what you want to achieve with this file and also what you are planning to do overall, and these are things that decide the future steps. In any case, take a look at the possibilities that services provide, maybe there is something that fits your needs.

Related

Where can I put my SQLite database in my QT application if I can't put it in my resources?

Recently I was trying to put a SQLite database into a QT 5 application I'm writing. I want it to be universally accessible - that is on all systems regardless of where it's installed. I put it as a resource then found out that evidently you can't put databases in resources as the string for the database path passed to setDatabaseName doesn't get translated to the resource system so the database can't be found.
So where can I put it? I don't want to just put it at the root of the drive like C:\repo.db or D:\repo.db as many people hate files cluttering their root directories (like me). I was going to put it just in the source folder and access it as "repo.db" or as I tried "./resources/database/repo.db" but even QFile doesn't see that. Where can I put it and how to access it there? My settings file was going to be in my resources but I wasn't sure if I could update the file then. I need a place that is available from the moment the application is installed on any system including my own so that it can be accessed both while coding it and when it's built.
I'm not asking for opinions - I want a place that is not in the root, somewhere universal like the installation directory (but how do I find that with code?) or a settings directory (but how do I set that somewhere so I can find it later??)
For such purposes Qt provides a list of QStandardPaths functions that return platform specific standard paths, such as a path to desktop, temp directory etc.
For your particular case you might put your database in the directory that corresponds to the QStandardPaths::AppDataLocation key.
You can use QSettings to save path,settings and restore them.
QSettings m_Arhive("Company", "app_name");
//Set DB path
m_Arhive.setValue("DBPath", "c:/somewhere/database");
//Get DB path
m_Arhive.value("DBPath").toString()

Where to save a program's config and save files on Windows?

What directory is the typical place to save files generated by a program, like a game or tool, when the file itself isn't necessarily useful on it's own? (i.e it's not a "document" like a text file or image that you'd want easy access to, instead it's just a config or save file you'd want to tuck someplace out of the way)
Does this change depending on if a program is "installed", as opposed to an executable free-floating in a folder? (For instance, is it standard practice to just save in the same folder in the latter case?)
If it's someplace that varies, is there a utility function I have to call to get a string of the path?
Check the Known Folder IDs for a tip. Most likely, you want FOLDERID_LocalAppData. Use SHGetKnownFolderPath() to retrieve the folder location.
Usually, I give the users the ability for "install" or "portable", in the latter case the app files goes into a folder under the portable installation folder.

get modified files after given timestamp in windows file system in Cpp code

Is there any way that I can get modified files/folders after a given timestamp in windows file system? I don't want to traverse entire file system and check which file/folder is modified in my code. Does windows provide any API which returns modified files/folders after a given time stamp ?
No, there is no direct WinAPI to accomplish this.
I'd suggest traversing only through certain folders (exclude folders like Windows, ProgramData) etc. Traverse only through the folders that make sense. ex: Users.
Why? Because the system files in Windows and such folders are accessed very frequently and are modified after system updates. Unless you're keen to see when the system files were modified, I'd say the data is going to be irrelevant and of no meaning.

Linked directory not found

I have following scenario:
The main software I wrote uses a database created by a simulator. This database is around 10 GB big at the moment, so I want to keep only one copy of that data per system.
Assuming I have following projects:
Main Software using the data, located at /SimData
DLL using the data for debugging, searching for data at /SimData
Debugging tool to parse the image database, searching for the data at /SimData
Since I do not want to have all those programs have their own copy of SimData (not only to decrease place used, but also to ensure that all Simulation data used is always up to date for all programs).
I created for the DLL and Debugging Utility a link named SimData to MainSoftware/SimData, but when opening a file with "SimData\MyFile.data" it cannot find it, only the MainSoftware with the ACTUAL SimData folder can find it.
How can I use the MainSoftware/SimData folder without setting absolute paths?
This is on Windows 7 x64
I agree with Peter about adding the DB location as a configurable parameter. A common place to store that is in the registry.
however, If you want to create links that will be recognized by your software, try hardlinks. . fsutil should do the trick as described here.
You need a way to configure the database location. You could use an INI or other configuration file, or a registry setting, or a command-line input, or an environment variable. Or You could write your program to search a directory hierarchy... for example, if the various modules are usually siblings of each other in your directory tree, you could search for SimData/MyFile.data, ../SimData/MyFile.data, ../../MainSoftware/SimData/Myfile.data, and use the first one found.
Which answer is the "right one" depends on your situation.

The Best way of storing/retrieving config data in Modern Windows

I've not done much coding for Windows lately, and I find myself sitting at Visual Studio right now, making a small program for Windows 7 in C++. I need some configuration data to be read/written.
In the old days, (being a Borland kind of guy) I'd just use a TIniFile and keep the .ini beside my exe Obviously this is just not the done thing any more. The MS docs tell me that Get/WritePrivateProfileString are for compatibility only, and I doubt that I'd get away with writing to Program Files these days. Gosh I feel old.
I'd like the resulting file to be easily editable - open in notepad sort of thing, and easily findable. This is a small app, I don't want to have to write a setup screen when I can just edit the config file.
So, what is the modern way of doing this?
Often people use XML files for storing preferences, but they are often overkill (and they aren't actually all that readable for humans).
If your needs would be easily satisfied with an INI file, you may want to use Boost.Program_options using the configuration file parser backend, which actually writes INI-like files without going through deprecated (and slow!) APIs, while exposing a nice C++ interface.
The key thing to get right is where to write such configuration file. The right place is usually a subdirectory (named e.g. as your application) of the user's application data directory; please, please, please, don't harcode its path in your executable, I've seen enough broken apps failing to understand that the user profile may not be in c:\Documents and settings\Username.
Instead, you can retrieve the application data path using the SHGetFolderPath function with CSIDL_APPDATA (or SHGetKnownFolderPath with FOLDERID_RoamingAppData if you don't mind to lose the compatibility with pre-Vista Windows versions, or even just expanding the %APPDATA% environment variable).
In this way, each user will be able to store its preferences and you won't get any security-related errors when writing your preferences.
This is my opinion (which I think most of the answers you get will be opinion), but it seems that the standard way of doing things these days is to store config files like these in C:\Users\<Username>. Moreover, it is generally good to not clutter this directory itself, but to use a subdirectory for the purpose of storing your application's data, such as C:\Users\<Username>\AppData\Roaming\<YourApplicationName>. It might be overkill for a single config file, but that will give you the opportunity to have all of your application data in one place, should you add even more.