Closed jo-mueller closed 2 weeks ago
Hey @jo-mueller,
thanks for the report! I will check the problem asap. But this bug also shows, that the plugin needs better exception handling, as problems with persistence shouldn't break the whole plugin...
By the way, recently I realized that the magicgui
package can store widget values on disk, so I'll check whether it would be a feasible solution.
Thanks again!
Hi @bauerdavid ,
thanks for the superfast reply :) Maybe another way to avoid this would be to write the plugin as a Qt widget from the get-go, rather than going the magicgui route? It's probably something for the next major version, but it would solve these persistence error problems and would maybe also make some of the "overhead layers" in the viewer unnecessary? (I take it that these are used to pass data between instances of the annotator plugin?)
Things like the Qt designer would certainly make at least the design of the UI relatively easy on that part.
Edit: Besides the design considerations, simply commenting out the self.clean_tmp()
made the plugin functional again. But I don't know the implications for ither functionality...
Okay, I was completely wrong :D This is not about widget persistence, but the temporarily stored image features used by minimal contour. My guess is that the temp files are not closed properly, so they cannot be removed.
The temp files are supposed to be removed by clean()
when Python exits (achieved by atexit). The self.clean_tmp
function runs on startup to remove any leftover temp files in case of something going wrong with the cleanup. This was done to make sure that the disk will never be flooded with leftover, as on Windows I've seen some cases where napari crashed and these files weren't removed.
I've looked into the code of the clean()
method, and I see the two empty except
blocks with no Exception type provided, which can be very dangerous.
So my theory is:
clean()
runs, there's an exception, but is not visible due to the empty except
blockclean()
from removing the temp files, also prevents clean_tmp()
from doing soI created a new branch and changed the handling of exceptions (from completely ignoring to printing the stack trace). Could you try it on the problematic machine? What I hope would happen is 1) the plugin won't break on exception and 2) We'll see what the problem is. Unfortunately there's some C/C++ and Cython code in the repository, if you have issues with installing, please let me know.
Hi @bauerdavid ,
sorry for not replying in such a long time. I just tried from your branch and I still receive an error but the traceback does seem to be a bit more verbose :)
Full traceback:
What puzzles me is that the script had permission to create the folder, but afterwards it doesn't have permission to delete it. Could you check if the user has write access, and also whether you can delete the folder/its contents manually? I started to experiment a bit, and what I found is that I'm actually able to remove the files the memmaps are using manually even when the memmaps are still in use. This means that removing currently accessed files is not the problem. I'm a bit stuck on what is causing this, I cannot reproduce it on my machine...
I just tried to forcefully remove it from the command line and got this:
(pytorch) johamuel@biapol-ws1:/tmp$ rm -rf tmp9zlwxwjq_nd_annotator/
rm: cannot remove 'tmp9zlwxwjq_nd_annotator/': Operation not permitted
I had a look at the permissions of these temporary files and this is more enlightening, I think:
drwx------ 2 saja957d pol_dye 4096 Jul 8 16:06 tmp9zlwxwjq_nd_annotator
drwx------ 2 saja957d pol_dye 4096 Jul 8 13:56 tmpolmrems8_nd_annotator
There are somehow two temporary folders from the nd annotator that were created by another user. Is it possible that the nd-annotator tries to reuse these and then fails in removing them?
yup, this should be it. Added code for ignoring PermissionError
s, check if it works.
Checked it, the change does fix the problem.
Describe the bug A collaborator of mine is receiving a permission denied error simply when opening the Annotator plugin. She is working on a workstation where she is having limited permissions (i.e., no sudo access).
This is the full traceback of the error message:
It seems like the
tempfile
package is trying to write something into the root tmpfile rather than into the users workspace, which would be a better go-to.To Reproduce Steps to reproduce the behavior:
Expected behavior Plugin widget should open without error
napari info Copy information from Help -> napari Info.
Suggested fix
Something to set the
/tmp
file to the user's homedir should probably do the trick, e.g.: