So far I had only most pleasant experience on this forum when it came to both technical and conceptual advises and solutions members have provided their insights for. Now I am looking for more cosmetic solution. What I have is a directory tree that consists of files and folders . My tool, once the path is provided has hardcoded location where is what and what needs to be done to execute the computation. The directory tree is always the same but i noticed users tend to open it and change some files inside to accommodate their particular use cases without properly addressing them through the API. As a result a huge mess is created and once these directories are shifted to another location for a different tool to be used it does not work anymore (and then I am to be blamed). Basically indexes are messed up and since it is a large data structure located inside it is very difficult to revert the changes. So my question is: Is there a way to archive the directory tree into one "file" but to allow the tools to use it as a regular directory with all paths written somewhere and full functional io operations, so that one cannot access it from outside ? (maybe some king do image file or something) and are there any small examples on how to do it in rust?
If such thing existed it wouldn't stop users from doing whatever they want inside, so what's the point of having it?
Have a look at sqlite. This will allow you to store data in one file, assuming you are ok with not having them exposed as files and directories but managed by you completely.
The idea would be that your application puts everything into a single directory and uses some sort of ID to know what they are and help maintain your internal bookkeeping, then there's another directory that end users can access or move around, where each file points back to the "canonical" version managed by your app.
App Data/
aaaa
aaab
aaac
internal_app_state.xml
User Data/
First/
some_file.txt -> aaaa
another_file.docx -> aaab
third_file.pdf --> aaac
We have something similar at work, where all mechanical models are stored inside a vault, but there's a background task which will populate a directory on a file server with read-only drawings that production can use. That way there's a canonical version that's managed by the app (our vault) and a "view" into that which won't mess up anything if users decide to move files around or accidentally delete them.
A better way would be to structure your app either so it's either not possible for users to meddle with the app's state except via your API (like a database), or design your app so it doesn't care if items are moved around or manipulated externally.
I'd prefer the database option personally because it's cleaner and more robust, but the latter could be done by relying on something which won't change when a file is moved, like your OS's equivalent of inodes. Or alternatively you can making the application stateless and not need to store indices, like a document translator or compiler.
U are right it is an X-Y problem but I always like to propose a version of a solution as to show that I am not only leaching of.... there is a long history behind this problem associated to various internal c-lib utilization that will be a pain to rewrite if a ground up build of a single file is to be pursued, Suggestion I posted are reactions on complaints of clients whose users are doing various "shady" hacks in these indexes. So I was asked if there is a way to somehow compile everything into a single binary file which will hopefully discourage such hacks. Many of these libs I did not write and some have lost their maintainers/authors (old libs) so now i have to figure out a solution that has a single file io behavior but effectively is a dir tree (and it needs to be executable on both win and linux machines)...
So I was hoping someone has already encountered such a problem and could share some wisdom. That being said, pointers so far have been very helpful. Thnx
