Some files showing up with 8exabyte size

[karibertils]

Hello

Some media files are showing up as 8Exabytes through rar2fs.

It's not too common but i keep running into those and this then breaks other software with overflowing integers etc.

You can see example of this happening on this file https://drive.google.com/file/d/1jmHbw0BbKw07xuXZJoQ4hlM9car_PqZi/view

[hasse69]

Thanks for the issue report. I checked the archive using unrar lt and this is what I get:

UNRAR 5.00 beta 7 freeware      Copyright (c) 1993-2013 Alexander Roshal

Archive: ***************************************.rar
Details: RAR 4, volume

        Name: ******************************************.mkv
        Type: File
        Size: ?
 Packed size: 99999890
       Ratio: -->
       mtime: 2052-07-18 08:36,000
  Attributes: -rw-rw-rw-
  Pack-CRC32: 4EEB8F13
     Host OS: Unix
 Compression: RAR 3.0(v20) -m0 -md=128K

As can be seen from this both size and modification time is corrupt and not valid. This archive was most likely created using a tool that does not comply completely to the RAR archive format or it has been corrupted on the way, the latter however very unlikely.

Users have encountered these kind of archives before and there was a workaround made for it here https://github.com/hasse69/rar2fs/commit/130a36403f9bbbc26149f636e8f20695346253e1 which is contained in the release v1.29.0 and later.

I mounted this archive using v1.29.1 and the workaround seems to be triggered.

-rw-rw-rw- 1 hasse hasse 1378928650 Jul 18  2052 *********************************************.mkv

The patch does not address the modification time problem which is left as is but the size to me looks good. Please report back what version of rar2fs you are using since you might be running a version which does not include this workaround.

[karibertils]

Thanks for quick response

Indeed, this was fixed by upgrading to 1.29.1

[karibertils]

I am still seeing this problem but more rare now, this time running on latest version from git v1.29.1-gita969ce5.

Here is example https://drive.google.com/file/d/1CK5U9gcWmM2tq6eF1BnHwuag0LuIhyGK/view

[hasse69]

I can confirm that your issue can be reproduced. Will have a look to why the workaround seems to fail in this case. Seems that the workaround it too strict and that this problem can be observed also for host OS:es other than Unix.

Archive: *************************************************************
Details: RAR 4, volume

        Name: *******************************************************************
        Type: File
        Size: ?
 Packed size: 49999864
       Ratio: -->
       mtime: 2016-01-02 13:16,000
  Attributes: ..A....
  Pack-CRC32: 9351788B
     Host OS: Windows
 Compression: RAR 3.0(v20) -m0 -md=128K

[hasse69]

A patch has been pushed to master as 53928fa566c17ac283bc8ce0e128c14469b31b7a. Please verify and report back.

[karibertils]

Yes this fixed the issue in all instances.

Thanks