Hacking Wii Backup Managers in GNU/Linux - WBFS Conversion Issues

[aphirst]

I've just spent the better part of 2 days trying to get Skyward Sword PAL (v1.00 and v1.01) to convert to WBFS to play in wiiflow-lite on my Wii U's vWii.

I'm a Linux user, and only have one (underpowered) Windows machine available, so I first attempted using various tools in Linux ("Wii Backup Fusion", "wit", and also "Wii Backup Manager x32" in wine). This worked for most games, but for Skyward Sword the result was always one of two things:

• The game crashes ("Exception DSI" etc.) when trying to load on the vWii, regardless of Backup Loader
• The Backup Loader crashes ("Exception DSI" etc.) when the loader attempts to render the Animated Banner from inside the game

I was particularly frustrated by the fact that the result from Wii Backup Manager in wine didn't work. I then tried using Wii Backup Manager on the Windows machine. I was using a USB Flash drive for this (source ISO and target wbfs/ folder), and again, after finally copying the result to the SD card, I got exactly the same issues.

Finally, I found an old USB HDD, and attempted the WBFS converstion again, still in Windows with Wii Backup Manager x64. This time, after copying again to the SD card, success! Skyward Sword PAL v1.01 was playing just fine in wiiflow-lite.

But what was going wrong?

Obviously I'm not entirely sure, but over the course of the next few hours I'm going to use all these tools again to generate WBFS dumps from the same source ISO, also documenting the command-line switches I used, and will attempt to compare the files themselves. I will also post checksums to attempt to ascertain whether the different tools can be coaxed into producing identical output - one thing which I know is true, is that the output from Wii Backup Manager is "reproducible", at least when run in Windows.

My end-goals are two-fold:

• This forum thread will show up in future searches, which means that other Linux users in the future might more quickly reach a solution
• Figure out why the WBFS dumps I was generating earlier don't work, either due to user error (me using the wrong options), or because of actual software error.

I will amend this post, or reply to it, soon, with the first batch of detailed tests and information.

 

[GreyWolf]

Try Wiimm's ISO Tools instead. Also, you're probably going to run into never-ending problems using a flash drive.

 

[aphirst]

@GreyWolf That's what I meant by `wit` in my initial post, yes.

I'm going to report on the output of various Wii ISO tools on various platforms, using various (md5sum-verified) ISO dumps. First some general comments:

• I initially believed that output from Wii Backup Manager differed when run in Windows or in Wine. I am now no longer able to reproduce this erroneous behaviour. I suspect the underlying issue was I/O operations being truncated prematurely, due either to initially using a Flash drive in Windows instead of an HDD (which I'm now using), or due to some instability bugs in Wine (unless using a Virtual Desktop, switching between applications can cause Wii Backup Manager to crash), which I ought to report later.
• Wii Backup Fusion uses wit internally, though a much older version, since the builds are from ~2011. As far as I can tell, using recent wit with the same command line options (which Wii Backup Fusion shows in its log) gives the same output files, despite the ~7 years of further development. I'll double-check this later.
• For wit I'm using "Wiimms ISO Tool v3.01a r7464 x86_64 - Dirk Clemens - 2018-04-10" from the Arch Linux repository
• While doing some digging, I found out about an older tool called wbfs_file https://www.reddit.com/r/wii/comments/6qhwtl/how_to_split_wbfs_files_properly/ - As will become clear, this tool gives identical results to Wii Backup Manager in some but not all cases, and is distributed with Win/Linux/Mac binaries and source (though I'm unsure of the license).

For all tests, the output of Wii Backup Manager will be used as a kind of "reference" when comparing filesizes and checksums, if filesizes match. For each game, for each dump, I will play to the first save point.

Skyward Sword PAL (SOUP01) v1.00
Unscrubbed ISO checksum: f32bd185cb71ec9d87d2a65c9385d3d8

• Wii Backup Manager, Windows or Wine
  • SOUP01.wbfs
    • Size in bytes: 4294934528
    • MD5: ed03b29e933abfe3530cd8c739e6befa
  • SOUP01.wbf1
    • Size in bytes: 295731200
    • MD5: 3b0ab0f21198ea07ff201c59e74c5751
  • This dump plays fine in wiiflow-lite off my SD card.
• Wii Backup Fusion v1.1, Windows or Linux (making sure to select "Split" and "4G")
  • SOUP01.wbfs
    • Size in bytes: 4294967296
    • MD5: 3ba31b6a557368d7006ff717db7c494b
  • SOUP01.wbf1
    • Size in bytes: 295698432
    • MD5: b4f6b7f3bfc1c9279f2e5db9380beeef
  • The "4G" split does not work as intended. It is not even possible to copy to a FAT32 disk! It's too large by 32K.
• wit copy file.iso --wbfs --dest . --psel DATA,UPDATE,CHANNEL --split --split-size 4G --section --long --progress
  • SOUP01.wbfs
    • Size in bytes: 4294967296
    • MD5: e004b5252ec3fd6ae8f50cae0aae2b40
  • SOUP01.wbf1
    • Size in bytes: 295698432
    • MD5: b4f6b7f3bfc1c9279f2e5db9380beeef
  • Since these are the options used internally by Wii Backup Fusion, one expects identical output, barring any changes to wit since Wii Backup Fusion's release. It seems that the "overflow" portion is identical, but the initial 4GB(+32K) has a different checksum. Different metadata from different versions of wit? Similarly, this can't even be copied to the FAT32 SD card.
• wit copy -z file.iso target.wbfs
  • SOUP01.wbfs
    • Size in bytes: 4294934528
    • MD5: bae00ad36fb96caf1cc0c176d8b6b280
  • SOUP01.wbf1
    • Size in bytes: 295731200
    • MD5: af1abb583d8a4dcca532ed99b693a762
  • These are the options which seem much more natural, when reading wit's documentation. The dump also plays fine.
• wbfs_file file.iso
  • SOUP01.wbfs
    • Size in bytes: 4294934528
    • MD5: ed03b29e933abfe3530cd8c739e6befa
  • SOUP01.wbf1
    • Size in bytes: 295731200
    • MD5: 3b0ab0f21198ea07ff201c59e74c5751
  • This dump is identical to that from Wii Backup Manager! Very interesting. Of course, this also plays fine, which should be clear even without testing.

So far we've learned that Wii Backup Fusion, or rather wit using the settings that Wii Backup Fusion gives it, splits inorrectly - not at 4G as the option states, but as 4G+32K, which renders the output totally useless. Since wit copy -z (-z is the same as --split) splits correctly, the issue is not with wit itself, but rather with the the options Wii Backup Fusion chooses to use. We've also learned that, at least in this case, output from the tool wbfs_file is identical to that from Wii Backup Manager, which suggests that they share code with each other (and write identical metadata), although the output from wit, which also works, is different in some way. I'm preserving all these converted files, so at a later date I can do some hex-editor analysis, or try out xdelta on them, or something.

I'm considering making a Google Spreadsheet for this information, since this is going to explode once I start testing more games, which for now will be in the following posts.

 

[aphirst]

Next, let's try a game which doesn't undergo splitting.

Super Mario Galaxy PAL
Unscrubbed ISO MD5: a8c962d1922f7521dc4b07348e4e8a51

• Wii Backup Manager
  • RMGP01.wbfs, size=3682598912, md5=bf74a08a91419d227e338a071cc1d078
  • WORKS
• Wii Backup Fusion v1.1, Split 4G
  • RMGP01.wbfs, size=3682598912, md5=c5aae5feb5e568707e9355ad46d4837a
  • WORKS
• wit copy file.iso --wbfs --dest . --psel DATA,UPDATE,CHANNEL --split --split-size 4G --section --long --progress
  
  • RMGP01.wbfs, size=3682598912, md5=14889a682ebf5c27c6d7c8ae6851b4e9
  • WORKS
• wit copy -z file.iso target.wbfs
  • RMGP01.wbfs, size=3682598912, md5=14889a682ebf5c27c6d7c8ae6851b4e9
  • Identical to the "long" wit command, WORKS
• wbfs_file file.iso
  • RMGP01.wbfs, size=3682598912, md5=bf74a08a91419d227e338a071cc1d078
  • Identical to Wii Backup Manager, WORKS

It seems that for this title, the output of Wii Backup Fusion is not identical to that from wit, with either set of flags. In fact, the output for both "runs" of wit is identical. I need to double-check what options Wii Backup Fusion actually uses when you don't select "split".

Let's try some different options for wit:

• wit copy --psel DATA,UPDATE,CHANNEL file.iso target.wbfs
  • RMGP01.wbfs, size=3682598912, md5=14889a682ebf5c27c6d7c8ae6851b4e9
• wit copy file.iso target.wbfs
  • RMGP01.wbfs, size=3682598912, md5=14889a682ebf5c27c6d7c8ae6851b4e9
• wit copy Super\ Mario\ Galaxy.iso --wbfs --dest . --psel DATA,UPDATE,CHANNEL --section --long --progress
  
  • RMGP01.wbfs, size=3682598912, md5=14889a682ebf5c27c6d7c8ae6851b4e9

It seems that the version of wit supplied with Wii Backup Fusion handles not-to-be-splitted games differently from the current version of wit, which, at least for this game, gives identical output for a diverse range of options.

 

[aphirst]

How about we try a Dual-Layer DVD game?

Super Smash Bros. Brawl PAL (RSBP01) v1.00
Unscrubbed ISO MD5: 549c19aefd56c3651571c32e3c32e5b3

• Wii Backup Manager build 78
  • RSBP01.wbfs, size=4294934528, md5=16946f19d5cf8c86bc7e760a8d94a012
  • RSBP01.wbf1, size=3363864576, md5=301cb82763a3195057c335a8183ec5f2
  • WORKS.
• Wii Backup Fusion v1.1
  • RSBP01.wbfs, size=4294967296, md5=af5fd0f2e829d14eec6d9a6bff3004eb
  • RSBP01.wbf1, size=3133145088, md5=507f20da223d12a7dcde15de20342425
  • As before, the first file is 32K too large. Cannot copy to FAT32 SD, so cannot test on console.
• wit copy file.iso --wbfs --dest . --psel DATA,UPDATE,CHANNEL --split --split-size 4G --section --long --progress
  • RSBP01.wbfs, size=4294967296, md5=757ba753d23ec4dfec5779bd96d42136
  • RSBP01.wbf1, size=3133145088, md5=507f20da223d12a7dcde15de20342425
  • Once again, the first file is 32K too large. Cannot test on console. Notice that, like with the Skyward Sword dumps, the "overflow" file part is identical, but the 4G(+32K) part is different, which again suggests something like metadata difference?
• wit copy -z file.iso target.wbfs
  • RSBP01.wbfs, size=4294934528, md5=811cd8e26aa0ab781f3a8861b6cd8e7b
  • RSBP01.wbf1, size=3363864576, md5=1c0155c13380a421712cd415bd1e6f27
  • WORKS.
• wbfs_file file.iso
  • RSBP01.wbfs, size=4294934528, md5=388d48ea09a11e4bd500320365cd72a2
  • RSBP01.wbf1, size=3133177856, md5=3ba0dadab3d2b0b0fab78f7c127c129c
  • WORKS. Though notice that it's ~220M smaller than the output from Wii Backup Manager. And exactly 32K larger than the result from Wii Backup Fusion. Very strange indeed.

So, to summarise what we've learned so far:

• There's obviously some sort of connection between wbfs_file and Wii Backup Manager. The similarities in their outputs is unlikely to be a coincidence.
• Wii Backup Fusion explicitly sets the --split-size for wit, which seems to be the common factor for all the wit outputs with the first file-part being too large. And when it is too large, it's always by exactly 32K, which suggests some sort of offset error, perhaps?
• Between Wii Backup Manager and wit there must be some kind of metadata difference in their outputs, which I would like to investigate further. Can anyone suggest where I might start?
• When using any of these tools:
  • Don't have your ISOs source or your WBFS target as being a flash drive - even if you call `sync` it seems this is prone to corruption.
  • Wii Backup Manager in Wine will crash if you don't enable "Emulate Virtual Desktop". This will corrupt any in-progress conversions.

I'm curious about that ~220M disparity for Smash Bros, especially given that the game still seems to boot. What could this data be?

Are any of the original developers of wbfs_file still around? In the readme for the version I found (v2.9), someone called "oggzee" is credited, along with some original authors "kwiirk" and "hermes". Is this perhaps of any interest to @Wiimm ?

My next step is likely to see if it's possible to, in conjunction with the Wii Ultimate Unscrubber, to regenerate md5sum-valid ISOs from these WBFS dumps. https://gbatemp.net/threads/wii-ultimate-unscrubber.452110/

 

[Ryccardo]

I'm curious about that ~220M disparity for Smash Bros, especially given that the game still seems to boot. What could this data be?

Update partition (2nd) and/or VC demos partition (3rd)

 

[aphirst]

Update partition (2nd) and/or VC demos partition (3rd)

I can view the partition contents with wit, right?

If that is the difference, the question then becomes, why this data is included or excluded respectively based on which tool, and which options were given.

 

[Ryccardo]

I can view the partition contents with wit, right?

If that is the difference, the question then becomes, why this data is included or excluded respectively based on which tool, and which options were given.

I don't know, never used wit to the best of my knowledge (which for the Wii practically ends in 2012; even then I wasn't a very big fan of usb loaders)

Most people using usb loaders wouldn't care about the update partition (they can't even meaningfully access) and not too much either about the VC demos (can be installed via a wad manager)/installable channel (same, and wouldn't forward to the HDD game when needed anyway - the cioscorp advantage ), so I wouldn't find it too surprising that some tools throw them away by default!

 

[aphirst]

Update partition (2nd) and/or VC demos partition (3rd)

I think you might be onto something.

I get this output when using `wit verify` on the version of Smash Bros from `wbfs_file`, i.e. the one which is 220M smaller than the others. https://ptpb.pw/DVaf

Spoiler: wit output wbfs_file

$ wit verify RSBP01.wbfs
***** wit: Wiimms ISO Tool v3.01a r7464 linux - Dirk Clemens - 2018-04-10 *****
!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#2003
!! Partition 0x50384148 ["HA8P"]: End of data (0x1daff0000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x50394148 ["HA9P"]: Offset of TICKET (0x1daff0000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x50414248 ["HBAP"]: Offset of TICKET (0x1dbaa0000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x46424248 ["HBBF"]: Offset of TICKET (0x1dc570000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x50424248 ["HBBP"]: Offset of TICKET (0x1dd0e0000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x50434248 ["HBCP"]: Offset of TICKET (0x1ddc50000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x50444248 ["HBDP"]: Offset of TICKET (0x1de720000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x50454248 ["HBEP"]: Offset of TICKET (0x1df1d0000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x50464248 ["HBFP"]: Offset of TICKET (0x1dfcc0000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x50474248 ["HBGP"]: Offset of TICKET (0x1e08b0000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x50494248 ["HBIP"]: Offset of TICKET (0x1e1490000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x504b4248 ["HBKP"]: Offset of TICKET (0x1e2490000) behind end of file (0x1da600000): RSBP01.wbfs/#0

!! ERROR in wd_check_part_offset() @ src/libwbfs/wiidisc.c#1992
!! Partition 0x504c4248 ["HBLP"]: Offset of TICKET (0x1e5d40000) behind end of file (0x1da600000): RSBP01.wbfs/#0

+OK .0 UPDATE RSBP01 RSBP01.wbfs/#0
+OK .1 DATA RSBP01 RSBP01.wbfs/#0

Whereas, if I do `wit verify` on the wbfs from Wii Backup Manager: https://ptpb.pw/LmQ1

Spoiler: wit output wii backup manager

$ wit verify RSBP01.wbfsd
***** wit: Wiimms ISO Tool v3.01a r7464 linux - Dirk Clemens - 2018-04-10 *****
+OK .0 UPDATE RSBP01 RSBP01.wbfs/#0
+OK .1 DATA RSBP01 RSBP01.wbfs/#0
+OK .2 HA8P RSBP01 RSBP01.wbfs/#0
+OK .3 HA9P RSBP01 RSBP01.wbfs/#0
+OK .4 HBAP RSBP01 RSBP01.wbfs/#0
+OK .5 HBBF RSBP01 RSBP01.wbfs/#0
+OK .6 HBBP RSBP01 RSBP01.wbfs/#0
+OK .7 HBCP RSBP01 RSBP01.wbfs/#0
+OK .8 HBDP RSBP01 RSBP01.wbfs/#0
+OK .9 HBEP RSBP01 RSBP01.wbfs/#0
+OK .10 HBFP RSBP01 RSBP01.wbfs/#0
+OK .11 HBGP RSBP01 RSBP01.wbfs/#0
+OK .12 HBIP RSBP01 RSBP01.wbfs/#0
+OK .13 HBKP RSBP01 RSBP01.wbfs/#0
+OK .14 HBLP RSBP01 RSBP01.wbfs/#0

And for the wbfs generated using `wit copy -z file.iso output.wbfs`: https://ptpb.pw/1ySH

Spoiler: wit output wit copy

$ wit verify RSBP01.wbfsS
***** wit: Wiimms ISO Tool v3.01a r7464 linux - Dirk Clemens - 2018-04-10 *****
+OK .0 UPDATE RSBP01 RSBP01.wbfs/#0
+OK .1 DATA RSBP01 RSBP01.wbfs/#0
+OK .2 HA8P RSBP01 RSBP01.wbfs/#0
+OK .3 HA9P RSBP01 RSBP01.wbfs/#0
+OK .4 HBAP RSBP01 RSBP01.wbfs/#0
+OK .5 HBBF RSBP01 RSBP01.wbfs/#0
+OK .6 HBBP RSBP01 RSBP01.wbfs/#0
+OK .7 HBCP RSBP01 RSBP01.wbfs/#0
+OK .8 HBDP RSBP01 RSBP01.wbfs/#0
+OK .9 HBEP RSBP01 RSBP01.wbfs/#0
+OK .10 HBFP RSBP01 RSBP01.wbfs/#0
+OK .11 HBGP RSBP01 RSBP01.wbfs/#0
+OK .12 HBIP RSBP01 RSBP01.wbfs/#0
+OK .13 HBKP RSBP01 RSBP01.wbfs/#0
+OK .14 HBLP RSBP01 RSBP01.wbfs/#0

It's obviously these demos which are being ignored by wbfs_file, perhaps since the tool is older, or it's hardcoded to only consider "normal" partitions? I'll have to consult its README.

 

[GreyWolf]

If that image was previously manipulated using Wii Backup Manager the partition table is probably irretrievably corrupted. It does not handle SSBB properly.

 

[aphirst]

If that image was previously manipulated using Wii Backup Manager the partition table is probably irretrievably corrupted. It does not handle SSBB properly.

For each game, I first verified that my ISO's md5sum matched the various online databases, and then for each ISO-WBFS tool/optionset, I did a fresh conversion from the ISO. I didn't (yet) do any franken-conversions (ISO-WBFS-WBFS etc.). Could you clarify what you meant by "that image"? It's not clear what exactly you're referring to.

 

[GreyWolf]

For each game, I first verified that my ISO's md5sum matched the various online databases, and then for each ISO-WBFS tool/optionset, I did a fresh conversion from the ISO. I didn't (yet) do any franken-conversions (ISO-WBFS-WBFS etc.). Could you clarify what you meant by "that image"? It's not clear what exactly you're referring to.

Did you rip the game yourself or did you download it? If you downloaded it I'm not sure what to tell you. A CleanRip version processed with WIT should work fine.

 

[aphirst]

The backups I have currently are all made using CleanRip, and as repeatedly stated, are all checksum verified. That was deliberate, in case anyone wanted to reproduce my results from their own discs (e.g. in the cases where one of the split WBFS files is identical, but the other differs).

The issue is no longer so much whether or not the WBFS-converted games "work" (since it turned out the actual issues on my end were the use of Flash memory for the conversion, and crashing issues in wine for Wii Backup Manager), but rather to document the various similarities and differences between the selection of ISO-WBFS tools, and to highlight my discoveries, and serve as a resource for anyone else in my situation in the future (especially regarding running Wii Backup Manager in a Virtual Desktop).

 

[Wiimm]

wit copy file.iso --wbfs --dest . --psel DATA,UPDATE,CHANNEL --split --split-size 4G --section --long --progress

With --split-size 4G you specify to split at 4GiB, not at 4G-32K. And the tool follow your command.
btw, you can also say: --split-size 4G-32K
Try: wit test --split-size 4G-32K

Between Wii Backup Manager and wit there must be some kind of metadata difference in their outputs, which I would like to investigate further. Can anyone suggest where I might start?

wit stores timestamps in unused space of the meta data.

 

[aphirst]

With --split-size 4G you specify to split at 4GiB, not at 4G-32K. And the tool follow your command.
btw, you can also say: --split-size 4G-32K
Try: wit test --split-size 4G-32K

Interesting. I suppose this is the reason that the default behaviour of -z is 4G-32K. I should look into why files on FAT32 systems have a limit of 4G-32K, not 4G - I genuinely thought it was 4G, so I've been a bit confused.

It might be a moot point now, since Wii Backup Fusion hasn't been updated in a long time, but it might regardless be worth someone (me) opening a ticket there, recommending against manually specifying 4G, which they do. Perhaps the old behaviour of 4G was to include this 32K offset, before the -z automatic splitting was introduced? I should look further into the development history of wit.

wit stores timestamps in unused space of the meta data.

Timestamps of what, of the source ISO file? Surely not from the system, otherwise I wouldn't be getting any kind of reproducibility. Is it possible to toggle this behaviour? I don't recall seeing this in the manual. Is it already understood whether or not Wii Backup Manager does this just with zeroes, or what?

 

[aphirst]

Did you rip the game yourself or did you download it? If you downloaded it I'm not sure what to tell you. A CleanRip version processed with WIT should work fine.

Did you mean specifically that Brawl would have issues when converted using Wii Backup Manager, but would work fine (assuming the source ISO was made with CleanRip and without error) if converted using WIT? If so, can you go into some more detail on what these issues are? I only tested brief play, but it seemed to work fine for me.

 

[Wiimm]

Perhaps the old behaviour of 4G was to include this 32K offset,

4G meant always 4G== 4*1024^3 = 4 GiB.
The default for --split is 4g (small letter). And 4g = 4*1000^3 = 4GB < 4 GiB.

Timestamps of what, of the source ISO file?

* mtime, ctime and atime (modification, status change, access) of original file
* itime : time of WBFS insertion

 

[aphirst]

4G meant always 4G== 4*1024^3 = 4 GiB.
The default for --split is 4g (small letter). And 4g = 4*1000^3 = 4GB < 4 GiB.

I see. Well in that case, Wii Backup Fusion was surely simply always wrong. I wonder how it ever worked for anyone in these cases?
Edit: I added a comment on WBF's tracker: https://sourceforge.net/p/wiibafu/tickets/9/#c208

* mtime, ctime and atime (modification, status change, access) of original file
* itime : time of WBFS insertion

Ah, so it's quite comprehensive. I don't recall in the manual there being a way to configure/disable this behaviour. Is this true?

 

[octoshrimpy]

@aphirst fellow linux user trying to figure out a worthy solution for posterity, lol.
WiiBaFu has been dead in the water for years, and so has qwbfs. Wit seems to yell at me for filesizes being too large often, too. I'm testing wiibafu with the 4G-32K as the split point, wondering if it works.

If there are any devs around that are willing to contribute, I have opened a github repo under octoshrimpy/wiisteria ( I cannot post links yet). It is electron-based, and will use wit as backend, since wit runs on every OS. Thank you @Wiimm for your awesome work, btw. <3

 

[evertonstz]

@aphirst fellow linux user trying to figure out a worthy solution for posterity, lol.
WiiBaFu has been dead in the water for years, and so has qwbfs. Wit seems to yell at me for filesizes being too large often, too. I'm testing wiibafu with the 4G-32K as the split point, wondering if it works.

If there are any devs around that are willing to contribute, I have opened a github repo under octoshrimpy/wiisteria ( I cannot post links yet). It is electron-based, and will use wit as backend, since wit runs on every OS. Thank you @Wiimm for your awesome work, btw. <3

Nice, I was going to start something but I'll wait someone more experienced do it. I'm watching your repository, for now I'm going to do some nasty scripts around wit to keep sending backups to my hdd.

 

[octoshrimpy]

for now I'm going to do some nasty scripts around wit to keep sending backups to my hdd.

if you'd like, if you figure out a way to do those scripts with nodeJS, they can be added as the background logic for Wiisteria. It'll be a frontend for WIT + TGDB data-grabbing + custom scripts anyways.