[ckan-discuss] Complete deletion of a resource

[Stéphane Guidoin]

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>