Open ghost opened 7 months ago
cant reproduce, just like upstream maintainer. What is mnt/sda filesystem/connection etc. Anything non-default you did to it.
Right! Sorry about that, I meant to state this when creating the issue: I am using ext4 and it is a USB connection. I've ran fsck and there are no badblocks. Also absolutely everything else seems to be okay with file I/O, aside from this particular issue.
This same setup was working fine on 22.03.05 but of course most of the packages changed going from kernel 5.10 to 5.15.
what does coreutils-stat show for the file? i cannot repeat on x86
root@OpenWRT:~# stat "/mnt/sda1/Private Torrents/VMware-TOOLCHAIN-ODP-70U3.iso"
File: /mnt/sda1/Private Torrents/VMware-TOOLCHAIN-ODP-70U3.iso
Size: 9186191360 Blocks: 17941792 IO Block: 4096 regular file
Device: 8,1 Inode: 104857604 Links: 1
Access: (0766/-rwxrw-rw-) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-11-30 23:31:42.116050311 -0500
Modify: 2023-11-27 10:58:46.285102400 -0500
Change: 2023-11-27 12:19:10.803382990 -0500
Birth: -
/just thinking aloud/ could be musl 1.2.4 dropping glibc legacy compat https://musl.libc.org/releases.html i will try maybe over weekend to build with that extra flag, though puzzled why x86 (32bit) did not catch same bug. if you run linux try to get sdk to build just one single package adding parameter.
@brada4 What filesystem did you test this with, on x86? Reading a recent response to my previous ticket on the transmission repo, it's possible this issue is connected with ext4.
xfs, not sure what upstream thinks of musl 1.2.4 rel notes.
Would it help for me to post this issue on the "main" openwrt repo instead? Or can we tag one of their developers here?
This is package issue - observable with this package but not coreutils.
Upstream transmission dev doesn't seem to think this has anything to do with musl
Upstream dev suggested building from a previous commit to see if that resolves the issue. I've never built a package before so it'll take me several days/weeks to be able to do this. If someone else has the capacity+ability to do this before then, please see the linked discussion on the transmission repo
Upon closer inspection, though I can create a torrent of the with the mktorrent package and it shows the right size for the files, but it creates incorrect hashes. So it seems both transmission-cli and mktorrent are unusable for me on this OpenWRT release.
It now seems even more likely that the issue is somehow either kernel related (concerning the ext4 filesystem), or it has some other connection to openwrt. For now I'm keeping the upstream ticket open, but progress is stalled there since I haven't been able to figure out how to build a package from a commit URL (as the upstream dev had suggested for troubleshooting purposes).
I havent got past that size in stat overflows and wraps, inconsistent hash invalidates both.
I don't understand that, but if there is anything more that I can do to help troubleshoot this issue, please let me know.
It should be repeatable in env close to yours. Just that not on simplest x86 setup.
This issue seems to still persist in Openwrt v23.05.3
Maintainer: @dangowrt Environment: ARMV7, IPQ806x, 23.05.2
Description:
transmission-create is unable to see the correct file size for most large files (beyond 2GiB or so in size).
This issue was first reported to the upstream transmission team and after testing they found the issue to likely be from stat() / lstat() calls returning the wrong file size in openwrt. Please see https://github.com/transmission/transmission/issues/6289 for full details and steps to reproduce