Open DanCardin opened 7 months ago
I'm experiencing the same "bug" triggered by a different method (library is an rclone mount). Also running unmanic as a Docker container.
Traceback (most recent call last):
File "/usr/lib/python3.10/shutil.py", line 816, in move
os.rename(src, real_dst)
OSError: [Errno 18] Invalid cross-device link: '/tmp/unmanic/unmanic_file_conversion-jltpr-1715075521/movie-jdbmv-1715077579.mkv' -> '/library/Movies/movie.mkv.unmanic.part'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/unmanic/libs/postprocessor.py", line 360, in __copy_file
shutil.move(file_in, part_file_out, copy_function=shutil.copyfile)
File "/usr/lib/python3.10/shutil.py", line 836, in move
copy_function(src, real_dst)
File "/usr/lib/python3.10/shutil.py", line 267, in copyfile
_fastcopy_sendfile(fsrc, fdst)
File "/usr/lib/python3.10/shutil.py", line 162, in _fastcopy_sendfile
raise err
File "/usr/lib/python3.10/shutil.py", line 142, in _fastcopy_sendfile
sent = os.sendfile(outfd, infd, offset, blocksize)
OSError: [Errno 9] Bad file descriptor: '/tmp/unmanic/unmanic_file_conversion-jltpr-1715075521/movie-jdbmv-1715077579.mkv' -> '/library/Movies/movie.mkv.unmanic.part'
I think it's because the dockerfile maintainer uses user "abc" instead of root.
Description
If a failure is encountered during the final copy step in post-processing here: https://github.com/Unmanic/unmanic/blob/master/unmanic/libs/postprocessor.py#L306, the job will appear to complete successfully in the UI, because the inner exception is caught and returned as a bool, but this call site doesn't check the result.
The result is that the job appears to succeed, but didnt!
Steps to Reproduce
I'm running unmanic in docker. My
/library
is an nfs mount, and i initially didn't set a volume bind for/tmp/unmanic
.This was yielding the following error on the aforementioned call site.
The error itself, i think it's a me, problem. It's the fact that I thought it was working correctly that's the bug here, to me.
Expected behavior: The UI should show that the job failed (and ideally why, the traceback)
Actual behaviour: it appears to succeed. Reproduces how often: 100%
Versions
The offending line is as described on master.
Installation Method Used
Docker