1/4/2023 0 Comments Nzbget extension chrome![]() os.rename works perfectly on network share mounts and copy/remove is not required in this case.Īnyway, I wonder why SABnzbd doesn't simply use os.rename in the first place.Ĭode: Select all 16:17:45,704::DEBUG:: Moving (overwrite: 0) /media/zeegat/incomplete/bla10GB/bla10GB.bin => /media/zeegat/_UNPACK_bla10GB/bla10GB.bin I can even watch how each file copied to "xyz" increases in file size during the copy process ad I can also see hard disk space being eaten up by the copied files.Īll this should not happen with an actual rename/move command.ĮDIT: as the "rename" happens on the same mount and hence on the same filesystem, this then seems then to be a bug in shutil. But this "rename" is clearly a copy process because on my NAS I can definitely see that both subfolders ("_UNPACK_xyz" and "xyz") exist in parallel during the copy process and the files and folders are successively copied to "xyz". ![]() SABnzbd does unpack from /tmp/xyz in the folder /downloads/_UNPACK_xyz and then "rename" /downloads/_UNPACK_xyz to /downloads/xyz. Nzbget extension chrome download#downloads is a mounted network share on my Synology NAS and the final download destination folder tmp is a local volume on a SSD on my docker server and is the temporary download folder for SABnzbd SABnzbd is installed in a docker container on my dedicated docker server (Ubuntu 14 LTS). I wonder why this has not been spotted so far and hope to see this fixed soon. And moreover, during the copy process, SABnzbd seems to be blocked (in my case web gui was stuck for about 15 minutes while SABnzbd was "renaming" a 50GB download). In addition this also might unnecessarily lead to problems with disks running out of space if files are copied and hence need double the disk space. ![]() Actually renaming the folder would take only a fraction of a second. This is incredibly slow and can take even more time as the unpacking process itself. I don't know if this is a new bug in v3.x or if this was also already present in v2.x (and I just never noticed it because my downloads usually go completely unattended) but today I have found out that after SABnzbd has finished unpacking the download into the "_UNPACK_xyz" folder, it does not simply rename the folder "_UNPACK_xyz" to "xyz" but it actually does copy the files from "_UNPACK_xyz" to "xyz" and delete them from "_UNPACK_xyz" thereafter. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |