Xbpartitioner 1.2 Release Candidate Options

[ldotsfan]

I've made a minor but important change to xbpartitioner 1.1 code. It reads the cluster size from the FATX superblock of the extended partitions and displays it on-screen. When formatting 32K and 64K clustered large partitions, this will confirm the actual cluster size used since the value is read from the hdd AFTER the formatting has been completed. I've only managed to test 16K and 32K by rotating among the existing supported partition schemes for F and G, ie F takes all, F and G splits equally and so on. 64K is untested since I don't have a hdd of that size.

I will only release the relevant changes in patch to the source code and not the binary for obvious reasons. I added one method and modified another method. And modified one struct.

Will attach the code in another post.








partition.h

CODE

typedef struct _FATX_SUPERBLOCK
{
    char    Tag[4];
    unsigned int        VolumeID;
    unsigned int    ClusterSize;
    USHORT    FatCopies;
    int        Resvd;
    char    Unused[4078];
} FATX_SUPERBLOCK;

PartInfo.cpp

CODE

wchar_t buf1[200], buf2[200], buf3[200], buf4[200],buf5[200];

unsigned int
get_clustersize(ANSI_STRING part)
{
    HANDLE hDisk;
    NTSTATUS status;
    OBJECT_ATTRIBUTES ObjectAttributes;
    IO_STATUS_BLOCK IoStatusBlock;
    BYTE PartSector[XBOX_HD_SECTOR_SIZE*8];
    LARGE_INTEGER RWOffset;
    FATX_SUPERBLOCK fsb;

    InitializeObjectAttributes(&ObjectAttributes, &part, OBJ_CASE_INSENSITIVE, NULL);

    RWOffset.QuadPart = 0;
    memset(PartSector, 0, sizeof(PartSector));
    
    status = NtOpenFile(&hDisk, SYNCHRONIZE | GENERIC_ALL, &ObjectAttributes, &IoStatusBlock, 0, FILE_SYNCHRONOUS_IO_ALERT);
    if (NT_SUCCESS(status))
        status = NtReadFile(hDisk, NULL, NULL, NULL, &IoStatusBlock, (PVOID) PartSector, sizeof(PartSector), &RWOffset);
    else
        return 0;
    NtClose(hDisk);
    memcpy (&fsb,PartSector,sizeof(PartSector));
    return fsb.ClusterSize/2;

}

void DrawTable(XboxPartitionTable *PartTbl, ULONG TotalSectors, int g_iCurrentPart)
{
    ULONG FreeSectors = part_get_free_sectors(PartTbl, TotalSectors);
    int i, offset = 8;
    unsigned int cluster_size;

    LARGE_INTEGER sz, free_sz;
    sz.QuadPart = (ULONGLONG) TotalSectors * 512UL;
    sz.QuadPart /= 1048576;
    free_sz.QuadPart = (ULONGLONG) FreeSectors * 512UL;
    free_sz.QuadPart /= 1048576;
//    swprintf(buf1, L"Disk Size: %I64uMB - %I64uMB Free", sz, free_sz);//((ULONGLONG) TotalSectors * 512UL)) / 1000000000000UL;
//    DisplayText(buf1, 50, 20 * g_ypos++, 2);

    g_ypos = 4;
    for (i = 0; i < 5; i++)
    {
        swprintf(buf1, L"%d", i+1);
        swprintf(buf2, L"start %.08x", PartTbl->TableEntries[i].LBAStart);
        swprintf(buf3, L" size %.08x", PartTbl->TableEntries[i].LBASize);
        swprintf(buf4, L"%.2f MB", (double) ((ULONGLONG) PartTbl->TableEntries[i].LBASize * 512) / 1048576);


        if (g_iCurrentPart == i /*&& PartTbl->TableEntries[i].Flags*/)
        {
            DrawRect(48, (float) (20 * g_ypos + offset - 4), 596, (float) (20 * g_ypos + offset + 20), 0xa0404040, 0xa0000000);
            DisplayTableText(buf1, 50, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 4 : 8);
            DisplayTableText(buf2, 84, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? (g_iMovePart ? 0 : 4) : (g_iMovePart ? 0 : 8));
            DisplayTableText(buf3, 258, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? (g_iMovePart ? 4 : 0) : (g_iMovePart ? 8 : 0));
            DisplayTableText(buf4, 592, 20 * g_ypos++ + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 4 : 8, XFONT_RIGHT);
        }
        else
        {
            DisplayTableText(buf1, 50, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf2, 84, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf3, 258, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf4, 592, 20 * g_ypos++ + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7, XFONT_RIGHT);
        }
    }

    g_ypos += 2;

    offset = 13;


    for (; i < 14; i++)
    {
        swprintf(buf1, L"%d", i+1);
        swprintf(buf2, L"start %.08x", PartTbl->TableEntries[i].LBAStart);
        swprintf(buf3, L" size %.08x", PartTbl->TableEntries[i].LBASize);
        swprintf(buf4, L"%.2f GB", (double) ((ULONGLONG) PartTbl->TableEntries[i].LBASize * 512) / 1073741824);
        cluster_size = get_clustersize(partition_str[i]);
                        if (cluster_size !=0)
                        {
                            swprintf(buf5, L"%dK", cluster_size);
                        }
                        else
                        {
                            swprintf(buf5, L"");
                        }

        if (g_iCurrentPart == i /*&& PartTbl->TableEntries[i].Flags*/)
        {
            DrawRect(48, (float) (20 * g_ypos + offset - 4), 596, (float) (20 * g_ypos + offset + 20), 0xa0404040, 0xa0000000);
            DisplayTableText(buf1, 50, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 4 : 8);
            DisplayTableText(buf2, 84, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? (g_iMovePart ? 0 : 4) : (g_iMovePart ? 0 : 8));
            DisplayTableText(buf3, 258, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? (g_iMovePart ? 4 : 0) : (g_iMovePart ? 8 : 0));
            DisplayTableText(buf4, 592, 20 * g_ypos++ + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 4 : 8, XFONT_RIGHT);
        }
        else
        {
            DisplayTableText(buf1, 50, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf2, 84, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf3, 258, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
             if(cluster_size!=0 && PartTbl->TableEntries[i].LBASize>0)
                DisplayTableText(buf5, 438, 20 * g_ypos + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf4, 592, 20 * g_ypos++ + offset, (PartTbl->TableEntries[i].Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7, XFONT_RIGHT);
        }
    }
}

[Bomb Bloke]

Ooh, handy! Indeed, many users get confused and think XBP is already informing them of the current cluster size. I tried to avoid that with the wording used in 1.1, though I don't think I was very successful.

There's also that silly crash bug when XBP sees a partition larger then 1tb. This is due to the "compare" variable in "PartInfo.cpp" being set to a ULONG - it's used to calculate the correct cluster size when formatting a partition, but overflows if used to check one of 1tb or larger. Quick fix is to just set it to a ULONGLONG or something. Note that it's dimensioned in two different places in the file, so both need to be tweaked. Same file also contains the the text telling the user what version of XBP they're running, in case you missed it; just do a search for "1.1" and you'll find it easy enough.

1tb partitions don't work anyway (no dash will read the resulting partition - dunno if this is a dash fault or a formatting fault), but the whole "crash-forcing-the-user-to-go-back-to-1.0" situation is hardly elegant either. I'd considered just enforcing a hard cap to partition sizes instead - even have a version that does that somewhere on my drive - but couldn't make up my mind as to whether this would simply make it harder for people to maybe later get 128kb clusters working. Didn't release either version as 1.2 as I wanted to make some more changes first, but was too lazy.

One idea I had on the table was to have XBP throw up a visual warning directly prior to formatting, noting that unchanged partitions would be left alone. Changing the behaviour so that it formatted partitions regardless of whether they were altered or not would be somewhat risky, as if a user got confused and asked XBP to format all partitions, it'd actually do it. As opposed to the current system, where it should only format the partitions that have had a new size set - which is admittedly not an intuitive one, but would be just fine if the users were properly warned.

Another was to make it so that the analog sticks could be used on the "help" page to re-calibrate the image on the TV screen.

All just some of the many projects I come up with then never do. A third was to have XBMC check the cluster sizes on all available partitions during its startup process. If it found any to be incorrect, it'd put up a visual prompt warning the user of the danger, and perhaps pointing them at a URL for a full document explaining what to do about it. Given that most people run XBMC a tad more often then they do XBPartitioner, this'd probably filter out many bad partitions before the users actually encountered data loss.

This post has been edited by Bomb Bloke: Jun 16 2010, 11:29 AM

[Heimdall]

Great work ldotsfan.

Another was to make it so that the analog sticks could be used on the "help" page to re-calibrate the image on the TV screen.

All just some of the many projects I come up with then never do. A third was to have XBMC check the cluster sizes on all available partitions during its startup process. If it found any to be incorrect, it'd put up a visual prompt warning the user of the danger, and perhaps pointing them at a URL for a full document explaining what to do about it. Given that most people run XBMC a tad more often then they do XBPartitioner, this'd probably filter out many bad partitions before the users actually encountered data loss.

These are excellent ideas. I had a quick look at the first one, thinking I could lift the screen resizing code from XBMC and reuse it, but it's way beyond my current programming abilities. (If I'm honest, I couldn't even find the code in XBMC to copy!!) Taking the cluster size checking code into XBMC is an even better idea.

Who says the Xbox 1 is dead?

This post has been edited by Heimdall: Jun 16 2010, 03:39 PM

[ldotsfan]

Pictures:
16K clusters:


32K clusters:
2.

A 256GB partition wrongly partitioned. I commented out some code to create an always 16K xbpartitioner in order to test this prior to this
3.

1. 128K may not be necessary now that we have multiple extended partition support in XBMC
2. Made the change to the version title.
3. Calibration screen will require major GUI redesign. An easier way will be to incorporate a subset of the partitioning capability into XBMC2XBOX which is after all a dash. I have some ideas on the feasibility and will explore further.
4. The ERR message is indicative of a partition formatted with the wrong cluster size for the partition size.
5. I've implemented Bomb Bloke's suggestion on the hard cap to partition sizes. IMHO, 1TB overflows not just for compare variable but my experience with xboxhdm3 tells me that the journey to 1TB and 128K clusters is a rough ride and there are many issues yet to be resolved, including a rewrite of oz_paul's partitioning code in the bios which is way beyond my ability. Hence I err on the safe side.
6. I have some ideas on how to incorporate the warning cluster size into XBMC. Log a warning into XBMC log file and treat the partition like an invalid remote path. Will explore further.

This post has been edited by ldotsfan: Jun 17 2010, 07:10 AM

[Bomb Bloke]

All sounds good.

If you define a partition but haven't yet formatted it, will it report ERR, or nothing at all?

Indeed, odds are no one will ever have a need to use 128kb clusters. Some people may want to put all their space on F, but really they'd just be throwing all their capacity into slack space.

A check-list for the cap: It needs to be enforced when "assuming" the partition layout for an unformatted drive during startup, when the user cycles through pre-set space layouts, and when the user manually attempts to alter the partition sizes. To memory I just threw something into the main program loop to see if each partition was in range, and lower the set size if not.

[lordvader129]

Indeed, odds are no one will ever have a need to use 128kb clusters. Some people may want to put all their space on F, but really they'd just be throwing all their capacity into slack space.

not necessarily, it would depend on how many/what kind of files they have

if its mostly xbox games, then yes, youll lose a significant amount to space due to slack on the hundreds of thousands of small files, but if they are keeping large files like movies or tv shows they slack difference may only be a few megabytes, which would be an acceptable trade for not having free space split between 2 partitions

its obviously not a priority, but not something id take of the todo list just yet either

one downside would be if XBMC would be made to handle 128k clusters i think it will be the only dash able to do so, so the F: partition wont work in any other dash (no loss if your like me and just use the xbox for movies)

also, i wonder if 128k clusters would have any issue with running games, would that be a bios thing?

[ldotsfan]

If you define a partition but haven't yet formatted it, will it report ERR, or nothing at all?

Nothing.

A check-list for the cap: It needs to be enforced when "assuming" the partition layout for an unformatted drive during startup, when the user cycles through pre-set space layouts, and when the user manually attempts to alter the partition sizes. To memory I just threw something into the main program loop to see if each partition was in range, and lower the set size if not.

It is done at the point of addition to partition size at the backend and not the GUI for my implementation.

Code:
1. PartInfo.cpp
2. partition.cpp
3. partition.h
4. XBMC patch. This will hide a corrupt FATX partition with the wrong cluster size and log a warning to XBMC log. It builds on the earlier multiple extended partition patch for XBMC.

This post has been edited by ldotsfan: Jun 17 2010, 04:00 PM

[ldotsfan]

The total sector count will overflow as well for a hdd sized over 1TB for 1.1.

I've made changes to the code to fix this. The capping of sizes wasn't done correctly earlier too.

[Spaceman2004]

Has xbpartitioner 1.2 been released yet? I'll soon be getting a 2TB drive as wondering if xbpartitioner 1.2 is coming out as a .xbe so I don't have to mess about with version 1.0 and 1.1.

Thanks for any info!

[wedders]

This would be a useful thing to have working. It seems to be XBP 1.1 is so near-perfect it's almost a crime not to see it fixed.

[Pericom]

Has the binary of 1.2 XBpartioner ever been released ? I cant find it..

[ldotsfan]

The tool was never finished. Given that hdd sizes above 256Gb come in 320,500,750,1000,1500,2000Gb only and for size of 1TB and above, F/G sizes can be simplified to 496,749,996Gb. Perhaps the tool can be further simplified.

[ldotsfan]

Should this be finished?

[Lipo]

Should this be finished?

please finish it
xbpartitioner is a very useful app, so any update will be great

[ldotsfan]

I'll find some time to do this. Will leave out the partitioning features Bomb Bloke suggested and focus just on the cluster size display.