Files don't get unrared if final filepath is very long

[billynews]

Hi,

I've noticed that files don't get unrared if the resulting (downloadpath + rar internal path + filename) filepath exceeds 259 characters.
They are just missing in the UnRAR Folder.

I've also noticed that Newsbin shows a size of 18446744 TB for these files on the "Files List"-Tab.

I will send you an example NZB and what to do to verify this.

Best regards,

billy

[Quade]

Yeah this is always problematic. Even though Newsbin uses UNC paths that are supposedly allowed to exceed 255 bytes total length.

I recommend keeping the download and unrar paths as short as possible.

X:\DL\

X:\Decode\

Don't use $(GROUP). $(NZBFILE) in the decode path might blow things over but most people use it.

[billynews]

Don't use $(GROUP). $(NZBFILE) in the decode path might blow things over but most people use it.

Yeah, I'm guilty - I used $(NZBFILE) but changed it after running into this problem.

It's unfortunate that there is no error message or something.

Btw. if I manually unpack with either WinRAR 6.23 or RAR 6.23 resp. this doesn't happen. So perhaps you can upgrade the RAR-version used by Newsbin

[billynews]

Is it correct that the subject you pass to a post-unrar script is $(NZBFILE) if I load a NZB from a NZB Watch Folder? It looks like it.

If yes, I could move the Unrar-Folder e.g. D:\DL to D:\$(NZBFILE) in a post-unrar script which would basically solve my problem.

I also noticed that the input files are deleted after the post-unrar script has finished which lets me check if all files in Output.txt
exists and if not move the Download Folder so that Newsbin can't delete it and I get a chance to manually unrar.

P.S.: Would it be possible to pass an additional parameter, the name of the NZB Watch Folder, to the post-unrar script?
If not, no problem. I could change my Download Folder from currently E:\newsbin\$(NZBFILE)\ for all NZB Watch Folders to E:\newsbin\pictures\$(NZBFILE), E:\newsbin\music\$(NZBFILE) etc.
and read the Input.txt and get the "category" from there.

[Quade]

The subject you see in the download list is doctored on the fly to include the NZB Filename. It's probably not sent during the post-unrar script. Just looking, it looks like you get the raw subject from one of the files. The NZB Filename is sent to the script.

I'm in the middle of making a test for really long file paths using the rared up NZB you sent. I suspect the issue is downloading and unraring to the same path where Newbin will actually unrar to a deeper temporary folder then move the files after the unrar. The issue is that you can have files inside the RAR set that overwrite the actual source rars so, you can't reliably download and unrar to the same path.

I'd say downloading to a unique path with $(NZBFILE). Then decoding to some other folder is the most reliable way to download.

X:\DL\$(NZBFILE)\

X:\Decode\$(NZBFILE)\

For instance.



The file paths in the rar you sent aren't THAT long.

[Moondawgie]

This is a reported problem with Windows. At least with Windows 10 Pro 64 bit.

Feedback Hub: No Longer Able to Create or use file names longer than 247 characters.

[billynews]

This is a reported problem with Windows. At least with Windows 10 Pro 64 bit.

This seems to be something different.

I can manually unrar the download with no problem. It's only a problem if Newsbin does the unrar.

[billynews]

Hi Quade,

I've written a small post-unrar script with Autohotkey which validates if all files from Output.txt are present in the Unrar-Folder.
If not, it displays a modal message so it doesn't exit, Newsbin doesn't delete the source files and I get the chance to manually unrar the download.

Code: Select all

Loop, Read, C:\Users\USERNAME\AppData\Local\Newsbin\Scripts\Output.txt
{

  if not FileExist(A_LoopReadLine)
  {
    MsgBox, %A_LoopReadLine%
    break
  }

}


It works well but then I noticed that FileExist() returns false for these files with long filenames even if they do exist!!!
I looked into it and in the end I found https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

After setting

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001


as described in the article FileExist() now works as expected.

Maybe you want to look into this article.

Best regards,

billy

[Moondawgie]

To my undereducated mind, that article seems to explain why WinRAR can write files with long "filenames" to Windows folders that can't then be renamed, deleted or moved using Windows File Explorer.

[Quade]

You have to use UNC pathing for long filename support to work.

"\\?\X:\Decode\"

So I did some testing and when I decoded to a different path than the RAR, all the files showed out out beyond 370 bytes. When I decoded to the same path as the rars, it used the temp folder, All the files that were longer than 260 bytes were lost. I believe they were decoded but the move to the decode folder lost the really long ones. It's something I'm fixing.

What I probably need to do is post a rar with huge path length then download so the entire decode chain is tested.

My version of Win10 can delete files longer than 260 bytes. It wasn't able to before. I assume MS finally updated Explorer to handle really long filenames. The recycle bin can't handle long file paths still. When you delete really long paths is reports it can't recycle them.

Edit: While Windows can support long file paths, it doesn't support them without jumping through hoops.