I'm trying to come up with a method to store image files long term in a manner where they can be accessed but not changed (Write Once Read Many)

  • Files will be ~1MB in size per, I don't expect to have more than 1000 or so over the lifetime. I may choose to burn a batch to CD/DVD for long term offline storage
  • I'd like them in a format where I can read the file at any time but not modify or delete it
  • new files can be added at any time in an automatic manner

I've looked at a few different options and I haven't found anything that works yet. The closest thing I found was using chattr to set the immutable bit on ext4. The downside of that is only root can set the bit, even if I own the file. I'd rather not go down that route if possible.


Why not simply mount the filesystem as read only?

If writing is scarce, you can remount it as read/write when saving the pictures and then remount it as read only afterwards.

  • Nope, requires root access to remount with different options. If I'm going to have a helper application that runs as root I may as well stick with chattr – mkomarinski Sep 12 '16 at 15:50

If you set these default ACLs on the directory:

setfacl -dm u::rx,g::rx,o::rx the-directory

Then files and directories created in it will be read-only (for everybody).

Note however that it doesn't prevent users from changing the permissions of the files they create afterwards.

Also note that it overrides the umask (it will make the files world-readable even if the umask would otherwise have restricted that read access).

  • I'm leaning this way as I only have one application that's going to drop files in there. I can set acls after adding the file to that location. I might just need to drop my requirements to "avoid accidental deletion" – mkomarinski Sep 12 '16 at 16:27

You could use version control, possibly with the VCS server on a remote computer. You can either set up multiple users (one with write privileges, one without) or just rely on the ability to revert changes if you make mistakes on your local checkout.

You get a few things "for free" like the ability to see if you've made any changes (intentionally or accidentally) on your local checkout, and the history of changes (e.g. when you added each file). It's also easy to keep multiple clients in sync (say you have a desktop and a laptop or want to share the repository with a friend) if they can all pull from the same master repository.

You still need to maintain the integrity of the VCS' filesystem, of course.

I just measured my own local SVN repo for binaries: it has 21,000 files (about 98% binaries), averaging 1.2 MiB each. Fresh checkouts over WiFi can take a little while :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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