Scenyx Entertainment Community > Xbpartitioner 1.2 Release Candidate

Full Version: Xbpartitioner 1.2 Release Candidate

Scenyx Entertainment Community > Xbox1 Forums > Hardware Forums > General Hardware/Technical Chat

ldotsfan

Jun 16 2010, 09:04 AM

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

Jun 16 2010, 11:22 AM

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.

Heimdall

Jun 16 2010, 03:35 PM

Great work ldotsfan.

QUOTE(Bomb Bloke @ Jun 16 2010, 11:22 AM)

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?

ldotsfan

Jun 17 2010, 07:08 AM

Pictures:
16K clusters:
IPB Image

32K clusters:
2. IPB Image

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

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.

Bomb Bloke

Jun 17 2010, 09:15 AM

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

Jun 17 2010, 09:48 AM

QUOTE(Bomb Bloke @ Jun 17 2010, 01:15 AM)

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

Jun 17 2010, 03:59 PM

QUOTE(Bomb Bloke @ Jun 17 2010, 04:15 PM)

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

Nothing.

QUOTE(Bomb Bloke @ Jun 17 2010, 04:15 PM)

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.

ldotsfan

Jun 18 2010, 06:27 AM

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

Nov 9 2010, 05:03 PM

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

Nov 28 2010, 10:52 PM

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

Mar 9 2011, 04:01 PM

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

ldotsfan

Mar 11 2011, 04:15 PM

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

Mar 21 2012, 02:47 PM

Should this be finished?

Lipo

Mar 29 2012, 08:34 AM

QUOTE(ldotsfan @ Mar 21 2012, 02:47 PM)

Should this be finished?

please finish it

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

ldotsfan

Mar 29 2012, 11:06 AM

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.

sarahchen

Apr 1 2012, 08:49 AM

Great in works

ldotsfan

Apr 2 2012, 02:46 PM

The cluster size version is done but somebody has to test it.

neophantom

May 10 2012, 02:37 AM

QUOTE(ldotsfan @ Apr 2 2012, 10:46 AM)

The cluster size version is done but somebody has to test it.

please let me do it!

ldotsfan

May 18 2012, 03:59 PM

I already tested it and there are bugs with the GUI and I don't have time to fix them now.

ldotsfan

Jul 27 2012, 04:21 PM

GUI problem fixed. Or rather I tried PhotoRec on an old image and recovered some old code.

ldotsfan

Oct 12 2012, 02:17 PM

I have started to migrate all LBA variables to ULONGLONG or 64 bit integers except when storing the partition table to hdd, discard the upper 32 bits.

Hopefully this approach will resolve the earlier issues of overflowing when large size hdds 1TB and beyond are used.

ldotsfan

Oct 13 2012, 05:05 AM

Code is done.

shambles1980

Oct 13 2012, 05:46 PM

have you compiled this and added it to xbins?

could be usefull.

ldotsfan

Oct 14 2012, 01:44 PM

1. Compiled XBE - Yes.
2. Testing - No.
3. Xbins - No. No access.

ldotsfan

Oct 17 2012, 04:28 PM

I did some basic testing with a small hdd but without the necessary equipment (1-2TB hdd and matching sata/pata adapter), I cannot test the desired functionality.

shambles1980

Oct 17 2012, 05:21 PM

i may be able to help
i have a 1.5 tb drive and a sata adapter but i havent confirmed the sata adapter is compliant with the xbox. it's in a mame project.

i will have to transfer files from the 1.5tb drive to other drives on my system before i can do any testing.

but send me a pm and il see what i can do about moving files tonight and a should be able to do some testing tomorrow.

Dawscaus

Nov 21 2012, 04:07 AM

I have a fresh 2tb Samsung HDD ready for an xbox and would like to try this out. Where can I find the xbe?

mike26

Feb 23 2013, 04:25 AM

I have modded a ton of 2tb drives and would love to use this and test this. Is there anyway to get ahold of it? I am trying to format the G drive of my 2tb sata drives to allocate 1.7TB and leave the F drive formatted 120gb 16kb Clusters so xmugen and linux play nice.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.