0

I am working on a C++ application which lets users work on projects. Each project consists of several files that should not be known / edited manually by the user.

For that we currently use a folder structure to store the settings, the files created by the user in the app and some automatically generated files.

We would like to have only one file to ease the opening of the projects (selecting one file with a dedicated extension is easier than selecting a folder), to ease sharing the projects and also to limit the risks of users tampering with the files.

My first thought would be to do something like Excel (create an archive containing all the files and put a custom extension on it) but if I do so I don't know how I should access the file from my app (do I need to extract the archive in a temporary folder while my app is running for example, and if so what happens if the app crashes/the computer crashes/...).

Are there any standards/ known and validated ways of doing this kind of things ?

9
  • Q1: Does it make sense for your C++ application to load all the files at once at the beginning, and save them at once, for example, when the user presses a "Save" button? Or do you need to read and wrote individual files? Please clarify!
    – Doc Brown
    Oct 25, 2022 at 12:17
  • Q2: is changing the file format(s) an option? Or do you want to keep as much as possible from the current file formats inside the single file? Please clarify.
    – Doc Brown
    Oct 25, 2022 at 12:19
  • @DocBrown there are several steps in the project each step read some files and write other files. There is only one step done at a time so usually I load just the needed files at the beginning of a step and unload them at the end. I don't need to open all the files at the start of the program. Changing the file format might be an option but I don't really see why doing this would change something...
    – f222
    Oct 25, 2022 at 12:31
  • Q3: Wouldn't be easier to define a descriptor? Say an XML or Json (or make your own format) per project, holding the reference to all the files involved? That's your meta-project file. An index or map.
    – Laiv
    Oct 25, 2022 at 12:32
  • 1
    ... because if you can change the file format, you could use a lightweight file-based database system like SQLite. That gives you the ergonomics of keeping everything in one file with the power of reading and writing arbitrary parts of it in a random-access manner, without corrupting your data in case of an application crash. If there is some kind of standard, then this.
    – Doc Brown
    Oct 25, 2022 at 12:32

1 Answer 1

2

Your comparison with Excel (and many other apps which do the same thing) is spot on.

ZIP archives can be manipulated from most programming languages relatively easily. You don't need to extract files into temporary folders but only need to change your app to read from and write to ZIP streams (plus some additional archive handling code to open/close the archive when appropriate). A quick internet search turned up https://github.com/Zipios/Zipios as a possible C++ library which even supports transparent handling of archive and regular files (note I did not test whether this is suitable for your purpose and what others exist, but it may be a starting point for your own search).

Unpacking into a temp file would only be necessary when an archive member must be used in a random access fashion, as I think the streams provided by the library are sequential.

1
  • Well, if there's concurrency, you might need to lock the files. For the sake of your sanity, you will create a temporal file and work on it and synchronize changes with the main data source (zip). If files are small enough, you can load as many streams into memory as you can, but if files are large (say gigabytes) it could be too much.
    – Laiv
    Oct 25, 2022 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.