kotiq / wt-tools

War Thunder resource extraction tools
29 stars 3 forks source link

Vromfs unpacker MAX_OUTPUT_SIZE results in different behaviour when run on *nix vs Windows #22

Open ftsartek opened 11 months ago

ftsartek commented 11 months ago

When unpacking char.vromfs.bin, a MAX_OUTPUT_SIZE of 5,000,000 results in variations of the following traceback when run on various Linux distros, and at least on MacOS 10.14:

$~ python -m wt_tools.vromfs_unpacker ~/char.vromfs.bin
Traceback (most recent call last):                                                                                                                                           
  File "../runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "../runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "../site-packages/wt_tools/vromfs_unpacker.py", line 234, in <module>
    main()
  File "../site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "../site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "../site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "../site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "../site-packages/wt_tools/vromfs_unpacker.py", line 230, in main
    unpack(filename, output_path, input_filelist)
  File "../site-packages/wt_tools/vromfs_unpacker.py", line 158, in unpack
    bs = get_blk_content(data_ns[i], dctx)
  File "../site-packages/wt_tools/vromfs_unpacker.py", line 58, in get_blk_content
    bs = dctx.decompress(node.data[1:], max_output_size=MAX_OUTPUT_SIZE)
zstd.ZstdError: decompression error: did not decompress full frame

Irrelevant of Python version, and sourced char.vromfs.bin from a few different locations. Running the packaged vromfs_unpacker.exe works as expected on Windows but in Wine on Linux results in the same issue.

Haven't been able to figure out why the differing results, but increasing this to 6,000,000 resolved the issue, suggesting something in char.vromfs.bin is right near the limit, and so it could be a difference in how *nix and Windows handle encoding?