I believe it's a (BAD) silent failure mode in the server code.

If I understand correctly, the purge request isn't coughing an error when
it gets to the 'allow_user_dataset_purge' check and instead is silently
marking (or re-marking) the datasets as deleted.

I would rather it fail with a 403 error if purge is explicitly requested.

That said, it of course would be better to remove the purge operation based
on the configuration then to show an error after we've found you can't do
the operation. The same holds true for the 'permanently remove this
dataset' link in deleted datasets.

I'll see if I can find out the answer to your question on the cleanup

On Tue, Mar 18, 2014 at 10:49 AM, Peter Cock <p.j.a.c...@googlemail.com>wrote:

> On Tue, Mar 18, 2014 at 2:14 PM, Carl Eberhard <carlfeberh...@gmail.com>
> wrote:
> > Thanks, Ravi & Peter
> >
> > I've added a card to get the allow_user_dataset_purge options into the
> > client and to better show the viable options to the user:
> > https://trello.com/c/RCPZ9zMF
> Thanks Carl - so this was a user interface bug, showing the user
> non-functional permanent delete (purge) options. That's clearer now.
> In this situation can the user just 'delete', and wait N days for
> the cleanup scripts to actually purge the files and free the space?
> (It seems N=10 in scripts/cleanup/purge_*.sh at least, elsewhere
> like the underlying Python script the default looks like N=60).
> Regards,
> Peter
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to