Closed forkicks closed 1 year ago
Didn't know it went over 100
In RarArchiveVolumeFactory.cs, if you add something like:
m = Regex.Match(part1.Name, @"^(.*\.[stuvwxyz])([0-9]+)$", RegexOptions.IgnoreCase);
if (m.Success)
{
item = new FileInfo(
Path.Combine(
part1.DirectoryName!,
String.Concat(
m.Groups[1].Value,
(index - 1).ToString().PadLeft(m.Groups[2].Value.Length, '0')
)
)
);
}
as another else before the "//split .001, .002", it should match the remaining archives (up to z99. I have never seen any real life examples going over it, and I'm unsure how the naming would change after that. Maybe a00?). I haven't created a pull request to fix this because I'm not familiar enough with the codebase to know if there are side effects of adding change here. You don't have to change any of the existing conditions or regexes, simply add this one before falling to the 001, 002 test (another if/else).
[edit: typo and code tag]
If you set WinRAR to generate according to old suffix it will go from z to { and then fail at | because it is not a valid file name in Windows. The default is currently name.partXXXX.rar
If a multivolume rar has over 100 volumes, the naming moves from r99 to s00, then up to s99, then t00, so on.
The way the code is set up in RarArchiveVolumeFactory.cs, it will only ever match up to r99, and fail to process more. This makes sharpcompress throw errors when decompressing those large sets of files.