Hi, Thanks for replying.
Your response confused me for a moment, but I've figured out the misunderstanding - this is not a file in the FAT filesystem which is larger than 4G, which as you say is impossible, this is just a disk which is larger than 4G. The rest of the program already uses 64bit variables and file apis so can support disks (or disk images) larger than 4G, there's just this one place (referenced in the patch) which stores the result of a 64bit calculation in a 32bit temporary variable. Regards, Harun On 27 Oct 2017 19:26, "Grégoire Passault" <[email protected]> wrote: Hello, Actually, fatcat only currently supports fat up to FAT32 which maximum filesize is 4G If you have a bigger filesystem, you are then using the extended FAT filesystem (alias exFAT) Maybe we could work on supporting exFAT in the future Best regards Grégoire Passault Le ven. 27 oct. 2017 12:51, Harun Trefry <[email protected]> a écrit : > Package: fatcat > Version: 1.0.5-1 > Severity: normal > Tags: upstream lfs patch > > Dear Maintainer, > > I tried using the fatcat utility to list directory entries on a disk image > with corrupted root directory entry, which was larger than 4 gigabytes. > This failed. > > I narrowed the problem down to a simpler recipe: the -@ option shows the > calculated disk offset to read for a given cluster number. > Given a large fat-formatted disk image test.img (10GB in this example), > asking for various disk offsets shows truncation as the cluster number > increases. > > # Correct > $ fatcat-1.0.5-old/fatcat -@ 250000 test.img > Cluster 250000 address: > 2058476544 <(205)%20847-6544> (000000007ab1dc00) > > # Wraparound to negative > $ fatcat-1.0.5-old/fatcat -@ 350000 test.img > Cluster 350000 address: > 18446744072292260864 (ffffffffab85dc00) > > # Truncated > $ fatcat-1.0.5-old/fatcat -@ 600000 test.img > Cluster 600000 address: > 630709248 (000000002597dc00) > > > After applying the patch below, the expected steadily increasing results > are printed, even after the 32-bit boundary: > > $ fatcat-1.0.5/fatcat -@ 250000 test.img > Cluster 250000 address: > 2058476544 <(205)%20847-6544> (000000007ab1dc00) > $ fatcat-1.0.5/fatcat -@ 350000 test.img > Cluster 350000 address: > 2877676544 (00000000ab85dc00) > $ fatcat-1.0.5/fatcat -@ 600000 test.img > Cluster 600000 address: > 4925676544 (000000012597dc00) > > > The patch is trivial, just changing a temporary from 'int' to 'unsigned > long long' before returning it from the function (which returns unsigned > long long). > > --8<------ snip patch > --- fatcat-1.0.5-old/src/core/FatSystem.cpp 2014-08-08 > 19:55:33.000000000 +0800 > +++ fatcat-1.0.5/src/core/FatSystem.cpp 2017-10-27 17:51:26.784312916 > +0800 > @@ -283,7 +283,7 @@ > cluster -= 2; > } > > - int addr = (dataStart + bytesPerSector*sectorsPerCluster*cluster); > + unsigned long long addr = (dataStart + bytesPerSector* > sectorsPerCluster*cluster); > > if (type == FAT16 && !isRoot) { > addr += rootEntries * FAT_ENTRY_SIZE; > > --8<------ snip patch > > > I haven't tested the directory listing operations I was initially > attempting, but I see no other obvious problems in the source which would > prevent it. > > The package doesn't seem too active upstream. > I have checked the github page and it still contains this bug, as does > current Debian testing and also the downstream Ubuntu copy of the package. > > > Hope it helps, > > Harun > > > > > -- System Information: > Debian Release: 8.9 > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, 'oldstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages fatcat depends on: > ii libc6 2.19-18+deb8u10 > ii libgcc1 1:4.9.2-10 > ii libstdc++6 4.9.2-10 > > fatcat recommends no packages. > > fatcat suggests no packages. > > -- no debconf information >
