8

I'm designing a GUI application that works with scanned documents. It allows the scans to be manipulated before they are saved/exported, so it needs to store the data for each scanned page temporarily while it is being worked on.

The amount of data is quite large (often over 100MB even with compression) so storing it in memory is not practical. It's also an onerous job scanning lots of pages, so the scans should be preserved in a "working area" on disk, so that even after rebooting the system the app can be reopened and the previously scanned data will be there ready to continue processing.

I am not quite sure where exactly I should be saving this important, but temporary, data:

  • /tmp/ is bad, because the data should remain after exiting and reopening the app, and even remain after a reboot.
  • $HOME/.config/appname/ isn't really correct, as it's not configuration data I'm saving.
  • $HOME/.local/share/ isn't correct, as the XDG spec says this is for overriding things like icons that are stored in /usr/share/ and there would never be "global" scans put in /usr/share/.
  • $HOME/.cache is close, but this isn't cache data and the user would be most annoyed if it got deleted after they scanned 100 pages and had to scan everything all over again.
  • $HOME/.local/lib/appname doesn't appear in any specs, but could be ok if .local means user-local (lib coming from /var/lib/ use.) If it means local to the machine then it's not a good fit, because the user should be able to log in to a machine with a high-speed scanner, do their scans with this app, log out, then log in on a normal PC and open the app to see what they just scanned - i.e. the data should be preserved across the network on logout, and ~$HOME/.cache needn't be shared among machines so $HOME/.local may not be either - I'm not sure.

So any suggestions on where the most appropriate place to store this kind of data might be?

EDIT: Just to clarify, this is per-user data, and the application is run as a normal user, so putting it in /var/ is probably not correct as you then have to handle multiple users running the application, aside from normal users not having write access there.

6
  • Isn't /var/cache customary? Take a look at the File Hierarchy Standard. Ok, if you think it isn't cache, then /var/tmp? As far as I know, it's also reasonable to create a separate "dot" directory for your app and put stuff in there.
    – Faheem Mitha
    Mar 12, 2015 at 9:51
  • @FaheemMitha: Anywhere in /var is going to be tricky as then it's up to me to (a) keep files for different users separate and (b) somehow create folders there when my app runs as a non-root user. For a system service this would be fine, but for a GUI app it really needs to sit somewhere under $HOME to avoid both these problems.
    – Malvineous
    Mar 13, 2015 at 1:51
  • As regards (b), any user can create files and directories (not folders) in /var/tmp. Try it and see. As regards (a), just prepend the name of a directory with the name of the user. I.e. username-appname-sometmpstring/ and put files for that user in there.
    – Faheem Mitha
    Mar 13, 2015 at 3:09
  • What do you mean by a user can create directories but not folders? I wasn't aware there was a difference between the two.
    – Malvineous
    Mar 13, 2015 at 6:31
  • I meant the correct term is directory, not folder. :-) Sorry if I wasn't clear.
    – Faheem Mitha
    Mar 13, 2015 at 7:09

2 Answers 2

Reset to default
1

I have a GUI application (using wxPython) that imports data from elsewhere before processing two to seven data files to produce a CSV file, a PDF report and, if selected, a number of other report formats. I store the source data files (until archived) and reports in directory structures in $HOME/Documents. This works well but you have to stress to Users that when they create directory names to make them sensitise and not give then nanes like qwerty, fred1, abc123, etc.

3
  • This could work, except the files in my case are raw data chunks and aren't suitable for direct access by users. So I would like to "hide" them away in an app-specific folder within $HOME, only because placing them in $HOME/Documents/ suggests that users are welcome to fiddle with the files - which sounds fine in your case, but will cause problems for me.
    – Malvineous
    Mar 13, 2015 at 1:45
  • I advise the Users not to access these files as you can only really do so with a hex-editor like Bless and then, unless you know the data structure, it would be fairly meaningless. Also changing these files could prevent production, or corrupt, the PDFs, etc. I out the configuration files in a hidden directory is the User's $HOME.
    – MichaelJohn
    Mar 16, 2015 at 11:11
  • 1
    Personally I would find it annoying if a program put files in $HOME/Documents that I wasn't able to move and edit as I saw fit - if you can't edit it then really it belongs in a hidden directory somewhere. I think advising all your users to treat a directory differently to how they normally would is counter-intuitive, and a good indicator that perhaps it's the wrong approach. But of course that just lands you in the same situation I'm in - where else do you put it??
    – Malvineous
    Mar 19, 2015 at 2:39
0

I use to create a subdirectory under opt with the name of my app and under this I put temporary and auxiliary files that my application use.

1
  • Unfortunately in this case, the data files are user-specific. So if I put them in /opt, I'd have to create a directory in there for each user to keep their files separate from other users, and figure out some way of creating the top-level folder for each user without having root access (the GUI app runs as a non-root user) so in this particular case, for a non-system app, I don't think anything outside of $HOME will be practical.
    – Malvineous
    Mar 13, 2015 at 1:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .