Workspaces and projects can’t be deleted in v2. Regardless of whether they are empty or not, attempted deletion gives an error message saying “can’t delete non-empty workspace”.
This is evidently a bug when applied to an empty workspace or project, but regardless I think users should be able to delete non-empty workspaces/projects.
If I want to delete a project, I shouldn’t have to delete each individual experiment and workspace within it - just give me a couple of confirmation dialogs to make sure that I am definitely, 100% sure I want to delete the project (or have a trashcan mechanism for deleted projects/workspaces, where they are not irretrievably gone until one empties the trash).
I also wonder whether it might be worth having a mechanism to archive old projects (I guess depends how efficiently they can be compressed as to whether it is worth it or not).
It would also be good to have a disk-cleanup job type to automatically delete intermediate files (and/or to have an option when running a job to control how much intermediate stuff is kept).
Deleting workspaces (after confirmation) and automated disk-cleanups are in the pipeline! Archiving projects will be something that is covered during the disk-cleanup procedure (removing process files and keeping metadata). There are a lot of edge cases to consider, so we’ll be adding features iteratively.
Any development on the disk/database cleanup features? The ever growing database is unmanageable, a relion-style local database would seem more sensible (each user would manage its own database, written in their user space instead of a global database).
If this is a notification, you can go to the notification manager (found inside the resource manager) and “clear” the orphaned notification. This sometimes happen when functions are terminated during execution and they don’t get to clear the notifications themselves.
I can click and delete projects from the UI, but they persist. Then if I try another import,
it says jobs are are already linked and it fails. But the projects referred to are one I deleted, supposedly.If I could clear the whole database of projects and start over, I would. Would that require
a reinstallation of cryosparc from scratch? Thanks for any clues for the newbie.
I am not the original poster but I can confirm this is still an issue with version 2.15.0. We run the master node on a RHEL 7 OS and the worked on CentOS 7. What we see in line with what previous posts claimed in the thread is that users are unable to remove projects or many jobs, if the number of jobs under a project is large.
The screenshot I uploaded shows two things of importance:
-Project P4 should have been deleted, yet it shows present with 345 Gigs of data on the Data Management tab to the right. This is also the case in the filesystem.
-A job to clear intermediate results from P7 was hanging.
We have tried to troubleshoot this by ensuring we did not run out of space (we didn’t) and restart the master cryosparc process various times. This did not fix the issues and we are unclear as to why we have a discrepancy between the state of the filesystem, the state of the project (deleted) and yet what shows in the data management field. It seems that the CryoSparc database does not update to reflect correctly the state of projects.
Can you please clarify why we have this behavior and what is the correct procedure to delete projects to regain space?