[fig2k4]

As I suspected, it was the block allocation table that had the FFs. It was a bug in the code I converted from.

The trim() function had this..
// make all block full
memset(p->freeblks,0,p->n_wbfs_sec/8);

When it should've been...

memset(p->freeblks,0,ALIGN_LBA(p->n_wbfs_sec/8));

and in Delphi..

ZeroMemory(FreeBlocks, AlignLBA(NumWBFSSectors div 8));

So I was only filling up to the size of the table with zeros, not to the end of the block, causing the free blocks (FF) to remain.

[oggzee]

Most modern unix files systems supports sparse files.

Including NTFS.

As I suspected, it was the block allocation table that had the FFs. It was a bug in the code I converted from.
....
So I was only filling up to the size of the table with zeros, not to the end of the block, causing the free blocks (FF) to remain.

Ah I haven't checked the offset of the 00 vs FF difference carefully, I just assumed it was a block of padding data.
Anyway, glad to hear you solved that, I take it you fixed the num_hd_sec too...

Edited by oggzee, 05 November 2009 - 12:58 PM.

[oggzee]

The trim() function had this..
// make all block full
memset(p->freeblks,0,p->n_wbfs_sec/8);
When it should've been...
memset(p->freeblks,0,ALIGN_LBA(p->n_wbfs_sec/8));

This made me check if that could be a problem in the existing code, but it doesn't seem to be, because:
p->freeblks = wbfs_ioalloc(ALIGN_LBA(p->n_wbfs_sec/8));
wbfs_memset(p->freeblks,0xff,p->n_wbfs_sec/8);
And while it is true that the freeblk allocation is lba aligned, only p->n_wbfs_sec/8 is used.
The rest is already set to 0 because wbfs_ioalloc already does that (at least my variant does it)
So, the original
memset(p->freeblks,0,p->n_wbfs_sec/8);
Will work fine and changing it to
memset(p->freeblks,0,ALIGN_LBA(p->n_wbfs_sec/8));
Will be ok too.
In other words, the current wbfs_file does not have this problem.
I assume you changed this:
wbfs_memset(p->freeblks,0xff,p->n_wbfs_sec/8);
To:
SetMemory(FreeBlocks, 0xFF, AlignLBA(NumWBFSSectors div 8));
Or whatever the delphi syntax is...

Edited by oggzee, 05 November 2009 - 01:09 PM.

[fig2k4]

I assume you changed this:
wbfs_memset(p->freeblks,0xff,p->n_wbfs_sec/8);
To:
SetMemory(FreeBlocks, 0xFF, AlignLBA(NumWBFSSectors div 8));
Or whatever the delphi syntax is...

That's basically what I did.

FillChar(FreeBlocks^, AlignLBA(NumWBFSSectors div 8), $FF);

If I didn't, the memory would be filled with junk anyway, not 0xFF. Since the extra part doesn't get used, the only time it matters is when it's trimmed so I think it'll be OK just to leave it like that. I could zero the memory, then set the correct size to 0xFF, but it's an extra step for nothing really eh?

I've posted version 0.1.6 with the fixes if anyone has time to test..

[oggzee]

That's basically what I did.
FillChar(FreeBlocks^, AlignLBA(NumWBFSSectors div 8), $FF);

If I didn't, the memory would be filled with junk anyway, not 0xFF. Since the extra part doesn't get used, the only time it matters is when it's trimmed so I think it'll be OK just to leave it like that. I could zero the memory, then set the correct size to 0xFF, but it's an extra step for nothing really eh?

I've posted version 0.1.6 with the fixes if anyone has time to test..

Yes, it's perfectly fine this way. I was just trying to clear why it works the way it is in wbfs_file, because I use:
#define wbfs_ioalloc(x) calloc(x,1)
To make sure there is never any junk in allocated memory.
(calloc will set the memory to 0, in case anyone wonders)

btw, in wbfs_file/libwfs_os.h i also commented this:

// some allocations are not cleared in libwbfs, so,
// we're using calloc to get always the same reproducible output
#define wbfs_malloc(x) calloc(x,1)
#define wbfs_ioalloc(x) calloc(x,1)

I was hoping it would be spotted, by whoever was modifying this

Edited by oggzee, 05 November 2009 - 01:50 PM.

[oggzee]

I've posted version 0.1.6 with the fixes if anyone has time to test..

I have tested it with WiiPlay and it creates binary exact same files as wbfs_file.exe
I have tested it with 'all' and with 'game only' partition selection and in each case the produced files are exactly the same as with wbfs_file -a or -g.
I haven't tested it with any game that would require splits.

ps. I have added a link to your wbfs backup manager in my cfg loader first post and fat faq.

Edited by oggzee, 05 November 2009 - 02:13 PM.

[fig2k4]

Nice. Thanks for testing.

[redia]

fig2k4,

just tested 0.1.6
the info file is there
the file are PERFECTLY identical..
I tested with two game below 2GB and two games over 2GB requiring split. all chunk are good.

R

[madtamski]

Brilliant, great work!

I was hoping something like this would come along

[FoGBaV]

Yeah ... thank you very much ... nice work !!

[redia]

fig2k4,

I have been doing some extensive testing.
including the ultimate test : I handed my mouse and keyboard to a noob and watched him as he was trying your app..

it is a pretty convincing piece of software you are building. I hope you will get to implement a few things from your todo list.

if you are looking for suggestion here are a few more :
- when a game is selected could you turn the whole line to gray.. it is much easier then to parse a list
- sortable columns (but I believe it has been asked already)
- folder history (when selecting a folder keep 3-6 quick access folder)
- recursive folder for iso/ciso... some people like to keep things clean.
- some way to get connected directly to wiitdb when click on the game.. could be an extra column with the link, or right click on the game, which will open the browser
- some export functions (TXT and/or HTML)
- a search box, or a filter box
- a setting to "minimize main window when copying games", this way we only keep the copy progress bar.

these are just a few ideas.. obviously you don't need to implement them all.
but I believe it is better to give you suggestion as early as possible during the project start, so you sort them out and pick the one you like.

Cheers,
R

Edited by redia, 05 November 2009 - 05:21 PM.

[FoGBaV]

i vote for the suggestion :

* Export function (HTML/TXT)
* rename id_title.txt with title.txt file from wiidb (some id_title.txt are realy saying nothing ..8) )
* hold a "i allready have" list of HDDs and titles (Games) ... just to have an overview which games we already own ...8)
(maybe sorted in release numbers an Region - there are some Collectors out there ...)

Edited by FoGBaV, 05 November 2009 - 05:14 PM.

[Sacohen9665]

I haven't had time to try the app yet, but I'm looking forward to it.
Oggzee tool worked great, but I'm not that great with command line apps.

I'm definitely hoping for a way to export a list of games to a csv list that can be brought into excel or something.

Thanks for the work.

[xzxero]

nice work man
i love seeing peeps out of nowhere with something really useful!

[XFlak]

i'm sure they'll come up with something, in the meantime u can do the following

create a text file in the directory where all your games are saved

open it

copy and paste the following:
dir > wiigamelist.xls

save the text document

rename the document's extension from .txt to .bat

double click the .bat file

it will create a file called wiigamelist.xls, which will list all the files the folder.

obviously this method isn't great, but hopefully it will tide u over