I found this bug while testing wimlib_split() with C# wrapper.
In many operating system (including Windows) and programs, string located after last dot of file name is treated as file extension.
So in the case of "D:\Hello.World.txt", the extension is .txt, not .World.txt.
But it seems wimlib thinks the extension of it is .World.txt.
This is a piece of code I used in unit test (written in C#), full code can be found here:
Code: Select all
string srcDir = Path.Combine(TestSetup.SampleDir, testSet);
string destDir = Path.Combine(Path.GetTempPath(), Path.GetRandomFileName());
string wimFile = Path.Combine(destDir, "LZX.wim");
// Strange, using "%TEMP%\{Path.GetRandomFileName()}" folder for split wim's dest raises an error
string splitWimFile = Path.Combine(destDir, "Split.swm");
string splitWildcard = Path.Combine(destDir, "Split*.swm");
This test eventually calls wimlib_split() with path like this, and expect these files to be generated:
Code: Select all
wchar_t* split = L"%TEMP%\\bz1qfs2t.gdk\\Split.swm";
wimlib_split(wim, split, (1024 + 512) * 1024, 0);
// (1) %TEMP%\bz1qfs2t.gdk\Split.swm
// (2) %TEMP%\bz1qfs2t.gdk\Split2.swm
// (3) %TEMP%\bz1qfs2t.gdk\Split3.swm
// (4) ...
Code: Select all
wimlib_split(wim, "%TEMP%\\bz1qfs2t.gdk\\Split.swm", 1024 * 1024, 0);
// (1) %TEMP%\bz1qfs2t.gdk\Split.swm
// (2) %TEMP%\bz1qfs2t2.gdk\Split.swm <- Failure
Tested Environment
- Windows 10 x64 1709 (Tested with both x86 and x64 binary)
- wimlib 1.12.0, with a C# wrapper