program abortion due to exception in fnmatch_all() #1996
Labels
needinfo
We need more details or follow-up from the filer before this can be tagged "bug" or "feature."
Comments
|
Do you think you could provide the exact message you're getting? Thanks 😄! |
jackwilsdon
added
the
needinfo
|
That may be possible - but it's far from sure. I ought to be able to produce a clean beets-system, restore the source, fill up the library with dupes, and then try to provoke the error... However, The error message seemed confused/confusing. The traceback referred to line 266 in the init-script. Line 266 then had this content: |
|
Well, we really do need to know which exception was raised so we know what to handle. Thank you! |
|
Is there some logging function that can be called to catch errors one is looking for, and log them to another file than stderr? |
|
If I provoke the program(s) in order to try to establish the same error messages, would it be enough with catching the exceptions like below, or is the exceptions you are asking for something else? the debug_log() printing to some dedicated file |
|
Honestly it would be better if the exception was thrown, as we can then see the stack trace. You can re-throw an exception by just doing Also what is the issue with printing to stderr? You can capture it to a file like so if you want: my_command 2> stderr_file |
Program was invoked with: The code there currently looks like this: |
|
The configuration for this run looked like this: |
|
The real culprit, it seems, must be the os.listdir() function. However, it's easier to catch an exception in python code than to wait for os.listdir() to become updated. The directory, that couldn't get listed now, is nothing particular: And for the curious, the directory listing looks like this: |
|
A similar exception from the os.listdir() function gets easily provoked: Results in: |
|
Finally, I avoided Jack's question:
Maybe it's because I'm inexperienced, daft, or something, but I can not see that it matters in this case. |
|
Do you think you could run this and provide the output? |
|
OK, sounds like we need to catch OSError, either inside |
|
The best way to do it IMO would just be to change this: # Traverse upward from path.
ancestors.append(path)
ancestors.reverse()
for directory in ancestors:
directory = syspath(directory)
if not os.path.exists(directory):
# Directory gone already.
continue
if fnmatch_all(os.listdir(directory), clutter):
# Directory contains only clutter (or nothing).
try:
shutil.rmtree(directory)
except OSError:
break
else:
breakto this: # Traverse upward from path.
ancestors.append(path)
ancestors.reverse()
for directory in ancestors:
directory = syspath(directory)
if not os.path.exists(directory):
# Directory gone already.
continue
try:
if fnmatch_all(os.listdir(directory), clutter):
# Directory contains only clutter (or nothing).
shutil.rmtree(directory)
else:
break
except OSError:
breaki.e. we move the except outside the |
|
Nice; I hadn't looked to see that we already have an exception handler there. If the current behavior is just to silently give up when the filesystem prevents further pruning, then this solution seems perfect. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sorry about not knowing much how to compose this kind of messages!
In the duplicates init.py, under def prune_dirs(), I've added a try-except-clause in order to avoid error and aborted run
It now looks like this:
Problem
I haven't really understood exactly what's going wrong.
(Maybe some day when I've more energy?)
The program aborts with a non-intuitive error message about too many levels of symlinks.
Setup
plugins: duplicates
My configuration is:
The text was updated successfully, but these errors were encountered: