[ckan-discuss] Complete deletion of a resource

Mon Aug 26 19:26:33 BST 2013

Thanks for the answer Sean!

If it can come with the next release of CKAN, it would be great. Although
resource deletion is clearly not an ideal option from a "open data" point
of view, it is the situation that can happen... and logging into the server
for such a reason is difficult to understand from the user point of view.

Cheers

On Mon, Aug 26, 2013 at 7:53 AM, Sean Hammond <sean.hammond at okfn.org> wrote:

> > *Short version*: Is there a way to fully delete an uploaded resource so
> > that even the file cannot be accessed anymore?
>
> I think the answer is pretty much no at the moment, although Nigel is
> working on a new version of CKAN's FileStore and I believe this feature
> is one of his aims.
>
> > *Long version*: From what I can see (CKAN 2.0), deleting an uploaded
> > resource via the web admin (or re-upload the same file) does not delete
> the
> > file. It just makes that the web page of the resource link the new
> > resource. But if someone, for a reason or another, has a direct link to
> the
> > file, that person might continue to propagate the "deleted" file.
>
> I think this is correct, yes.
>
> If you can locate the uploaded file in your pairtree storage directory
> and delete it, I guess that would get rid of it.
>
> > Obviously, we would prefer a good old 404...
>
> Yes.
>
> > The only option I see is to manually erase the file in
> > the DB which is something we would like to avoid because it is obviously
> a
> > risky business to directly manipulate the DB content.
>
> Well you'd erase it from the pairtree storage directory, not the CKAN
> SQL database itself.
>
> _______________________________________________
> ckan-discuss mailing list
> ckan-discuss at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-discuss
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-discuss/attachments/20130826/f7e26c71/attachment.htm>