newsbin.com

I have noted auto unRAR paths that are longer than MAX_PATH (260 characters for a file and 248 characters for a diectory) that result in "UnRAR Failed" status. Interestingly, I have also noted auto unRAR paths that are not longer than MAX_PATH, though close, that also result in "UnRAR Railed" status. Below is an example of the latter with an indication of a similar example of the former.

I'm using version: 6.01B5: 00 BB F1 9C 56 20

Here's an example for a typical download & UnRAR path I might use: H:\!_AstraWeb\2011-08-17\ThumperX\

34 character; does not seem excessively long as a start point.

Here's an example of an UnRAR path v6.01B5 might create that seems OK, but does not unRAR successfully:

H:\!_AstraWeb\2011-08-17\ThumperX\=============Flower Is The Skunk=====================\=============Flower Is The Skunk=====================_part001_rar\=============Flower Is The Skunk=====================\=============Flower Is The Skunk=====================.pdf

Close to the limit, but not at or over. However, I might still receive the "UnRAR Failed" error and if I "manually" unRAR this set with the same path above, but without the "=============Flower Is The Skunk=====================_part001_rar" directory, unRAR is sucessful.

An example of clearly over the limit would be with
"=============Not only is Flower the skunk, but Thumber is the Bunny Rabbit===============" in place of
"=============Flower Is The Skunk=====================" -- each subdirectory is longer so the full auto unRAR path is way over MAX_PATH.

Would you consider shortening the automatically created UnRAR path so there are fewer subdirectories and/or shorter full paths?

Thanks, Fred.

Please don't post specifics of what you're downloading in the forum. In future, please obfuscate it...

DT

OK will do. These were intended to just be examples of what could happen. They were not intended to represent attempted downloads. Just good examples. I guess I made them too "real world". I'll make future examples less "real world". Sorry.

The problem is the RARS sometimes contain pathing too in addition to however deep you have the download or unrar path set to. I'd recommend at the very least downloading to and unraring to shallow folders.

"C:\DL\" for instance. That's give you the most room for the other pathing.

I agree. At the same time, I note that this is a "new to v6" feature because of the extra subdirectory level created in the unRAR process.

I've used H:\!\ since this is the shortest you can get except for the drive root and "!" sorts at the top of the list. Sort of inconvenient to override the unRAR folder all the time, have days of downloads and unRARs all smushed into the same directory, or unRAR the posts "manually".

The "Blah-Blah-Blah_part001_rar" subdirectory that v6 adds to the unRAR path is the major new contributor to the unRAR path length increase. I have no clue of the design rationale that led to the additional unRAR directory level (I am curious though if you are willing to share), but since this appears to be a temporary directory that gets deleted unless something gets "left over" (all the final unRARed files are moved up one directory after unRAR complete, so this extra directory branch seems superfluous ... ?), please consider shortening its name to "unRAR" or somesuch much shorter than the post-related name.

Also, any idea why unRAR paths close to, but shorter than MAX_PATH cause the "UnRAR Failed" status?

Thanks.

Sort of inconvenient to override the unRAR folder all the time,

You can just set it to unrar someplace else in the options too.

I never run into this issue so, the question is to ask your posters is why they feel the need to have 200 byte long paths in their rar files. One option might be for me to simply turn off the unrar path of it's too long. I can't really control how long the path it uses is, but, I could probably disable the embedded path on a case by case basis. Newsbin could use any path length. The code is in there but, disabled because once you go beyond 255 total chars, Windows Explorer can't manipulate the files.

Quade wrote:Newsbin could use any path length. The code is in there but, disabled because once you go beyond 255 total chars, Windows Explorer can't manipulate the files.

Would be nice if that could be exposed as an option. My UnRARs go directly to ZFS (over loopback fake smb-server) on the Solaris host running the VM with newsbin, so I don't exactly need no stinkin' exploder to get to the files:-)

- mho

I'll have to think about it. It's not trivial to turn off and on. MAX_PATH is used throughout. To go greater than 255 chars you have to use unicode (not a problem) and have to use UNC naming for the paths. That might be a problem.

Maybe I can get the RAR lib to report the path but, not use it then move the files in my code.

Quade wrote:I'll have to think about it. It's not trivial to turn off and on. MAX_PATH is used throughout. To go greater than 255 chars you have to use unicode (not a problem) and have to use UNC naming for the paths. That might be a problem.

Yes, I guess it might be possible/easy to have dual versions of some functions and a runtime switch, but it depends on how many places actually touch the disk, etc. No idea how your code is organized. (Thankfully, most unixen have had PATH_MAX at 1024 for decades - not unlimited, but mostly enough:-))

- mho

Hi Guys, just to update you, finally I found a way to solve it
Do you have error messages?, like :

* Path too long
* Error cannot delete file: cannot read from source file or disk
* Cannot delete file: Access is denied
* There has been a sharing violation.
* Cannot delete file or folder The file name you specified is not valid or too long. Specify a different file name.

For that I tried it with: http://longpathtool.com/