I attempted to implement this a while ago, but came up against the issue with atomicity - a file could be written while the liberation object is still in a transaction (i.e. we can't read it in our process). There was no way I could be sure this file wasn't being referenced somewhere.

One way we could get around this is to have a separate LiberationFile model and give the Liberation model a nullable relation to the new model. That way we only need to search for LiberationFile objects that aren't referenced by a Liberation object. Any transaction funniness can be dealt with there and we can safely delete that object and then the file (I think there's a post-commit thing we can use?).

Another option would be to only move files to the final liberation folder once they've been finished with - i.e. we know the Liberation object will already be committed. This option is a lot easier to explain and implement, so I think that's what we'll do ☺