3.4.0RC1 Error: Cannot create final folder & Volume Label Syntax issue

[RKM]

SABnzbd version: 3.4.0RC1
python version: 3.9.6
mode: tested both: running as service -and- running direct from command-line, service uninstalled

Notes:
[*]I've never had problems in any previous releases of SABnzbd
[*]None of my settings have changed
[*]Once I upgraded to 3.4.0RC1, these errors started
[*]I updated Python to 3.9.6 at the same time as upgrading SABnzbd. Could this be the issue?
[*]The service is setup under an explicit account that I've verified has access to the share (as it always has been).

Relevant Errors from the Log:

Code: Select all

OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\UNC\\'

2021-09-11 12:20:16,374::ERROR::[postproc:706] Cannot create final folder \\?\UNC\10.10.10.11\ShareName\FileName

Errors thrown in UI

Code: Select all

File "sabnzbd\filesystem.py", line 656, in create_all_dirs
File "os.py", line 215, in makedirs

I've only replaced the share-name and filename; everything else is exactly as shown in the log.

You can see the issue is with this strange: \\\\?\\UNC\\ -- then later: \\?\UNC\ (rather than "\\")

I've noticed this error twice in the past, when searching the forums. In each case you mentioned Python issues and posted a hotfix. I'm not sure if that's related here, but I thought it couldn't hurt to mention.

Thank you in advance

[sander]

If you think it is related to SAB version, can you try the previous version?

[RKM]

Sure!

At your request, I installed the current release (3.3.1). The problem remains.

However, this is not the version I was using prior to the upgrade. Unfortunately I didn't look before upgrading, but I'm fairly certain I was on 3.0.0 because it's been well over a year since I've upgraded.

I don't necessarily think it's SABnzbd; I just noticed two earlier issues at different points in the dev cycle that were identical and fixed as a result of the bug reports. I thought I should mention it.

If it's not SABnzbd, that's certainly possible. I'm just at a loss because nothing else changed. I preserved my configuration from the prior install and I also double-checked the actual .ini file, once I noticed the problem -- confirming there was no corruption and the paths were stored properly, etc.

Did you notice I included the line-numbers? Is there any situation you can imagine that would cause SABnzbd to create a path as "\\\\?\\UNC\\" or "\\?\UNC\" when that doesn't exist anywhere in my config?

Thank you!

[sander]

but I'm fairly certain I was on 3.0.0 ... I'm just at a loss because nothing else changed.

If you really think that, downgrade to 3.0.0, and try again.

I just noticed two earlier issues at different points in the dev cycle that were identical and fixed as a result of the bug reports. I thought I should mention it.

Where? Can you post the URLs?

Checking: you're on Windows, but running from SAB source? As you say you installed a python version.

I would do this: change folders to C:\ based folders. If that works, you can try introducing a network drive for your complete / final folder.

[RKM]

1. At your suggestion, I switched to 3.0.0 and with the same exact settings, nothing changed, it works without error.

However, 3.31 and 3.40RC2 both have the error.

2. I'm running on Windows 10, I run LTSC and don't run updates -- nothing has changed there.

3. I run the full SABnzbd installer (not source). In other words, I completely uninstall (keeping settings) -- download the full installer package (eg- "SABnzbd-3.3.1-win-setup.exe") -- and follow the normal install process. Nothing special, nothing custom.

4. The Python runtime is the version included in SABnzbd. This is the reason I asked in my last post, whether SABnzbd still includes an embedded Python, which I see now that it does.

5. As your request, In version 3.31 and 3.40RC2 -- I tested both C:\temp and \\10.10.10.10\C\temp -- running directly under the Administrator account (the actual explicit Administrator account, not an account that has Administrator rights).

C:\temp ... works fine.

\\10.10.10.10\C\temp ... (identical path using URC) -- receives the following error:

Code: Select all

OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\UNC\\'

Again, I just tested these in 3.0.0 and they worked fine.

5. This is addition proof this is not a permissions issue or network related. It's a bug in SABnzbd with UNC paths. This can be proven: (a) it works on the 3.0.0 version without changes. (b) I've done exactly the same thing SABnzbd is doing, under the same account (running SABnzbd explicitly by the .exe, not as a service and not impersonating another usr).

To repeat: I can create a directory directly from Explorer or Command Line, under the same account (Administrator) that I'm running SABnzbd (not as a service, direct for diagnostic purposes) using that same local UNC.

2b. Again, I'm just running thestock/default SABnzbd installer with the version of python that SABnzbd includes. I'm not running any sort of source-based or custom install. Apologies for my misunderstanding earlier.

[safihre]

The strange notation is Windows-long-path notation and it's the correct one for network paths.
We did make some changes in the versions between 3.0.0 and 3.4.0, but I am surprised only now this would pop up, would expect more users to complain about it.

Just to be sure, could you send me the whole log at [email protected]? Without removing your specific paths, so I can trace back all the steps what SABnzbd is trying to do.

[Puzzled]

It's possible that his LTSC version handles this differently than the current W10.

[RKM]

@Puzzled - You have an amazing eye for detail, that's a brilliant suggestion. If this problem is not being reported by many uses, it's highly likely that it would relate to something specific with my environment. Being an that I run Win10 as the LTSC edition, that would make perfect sense.

@safihre - I'm currently packing to jump on a flight. I'll try to quickly re-install v3.4.0RC1 (because 3.0.0 runs fine, I had originally gone back to that) - and then email you the log directly, without removing the path.

Thank you