Party Buffalo 2.0.1.0

FUR COAT YALL

 

Hello everyone,

It’s been a while since I’ve written on this blog, and since I’ve updated Party Buffalo. A friend of mine was trying to use my cross-platform FATX explorer, and it didn’t work for him. I thought that it was odd, since the FATX libs should be 100% solid as far as reading and disk size calculations and all that crazy stuff goes.

Well, I was wrong. Here was the problem, which also applied to Party Buffalo: I was using the raw disk size, and not the actual size that the Xbox uses from the security sector. So, for some disks, the size of the file allocation table would be off by +- (around)0×3000, give or take, which would then make the data region of the Data partition off by that amount as well, therefore giving the user bad (just random) filenames and other weird stuff happening.

I said this before, but this is almost 100% guaranteed to be the last update for Party Buffalo, unless I really screw up this update. I’ve since moved on to other projects. I’m starting to get in to web development (Ruby on Rails to be precise), and this project has lost my interest. I was debating finishing Up, but then two friends of mine showed me the awesome work they’ve done on their cross-platform STFS package manager (also does a lot more than just that!) called Velocity. They made the excellent point that it’s useless on non-Windows platforms without a device explorer. So, I’ve started to start development on Up again, and hope to have it done this winter.

Some reflections on Party Buffalo, and CLKsFATXLib:

I would have designed them both a lot differently. Looking through the source, I realize how much I didn’t understand when I started off, and how much better I could have made both projects in terms of performance and source structure/readability. Things got messy. Things got ugly. I sort of started to do that with the Drive class in Up’s FATX library, but I plan on sorting that out before the project is done with (how about this weekend?). I also probably should have made the update system a lot nicer, and shouldn’t have done that bullshit with the ads/latest news stuff. No one cares about that. It was annoying. I did it because the person who was hosting my server before suggest I do it in order to gain ad revenue for both myself and him. So, sorry for subjecting you guys to that.

I also probably should have used some kind SVC. Seriously. I started coding Party Buffalo when I was 13 I believe. I didn’t know what SVC was, so I didn’t use it. It was only at the end of the project that I finally uploaded the source to Google Code, and in hindsight I probably should have just uploaded it to GitHub. Zipping up the source and uploading it to a dump site really wasn’t the best solution (and it’s what I’m doing for this release, since I’m too lazy to reconfigure Google Code stuff and set it up on my GitHub page).

Per usual though, you can find the sources at http://clkxu5.com/drivexplore/src/. I did not provide CLKsFATXLib with its own source in the subfolder. Just grab the latest DLL if you need it.

To all of you who still use Party Buffalo: thanks for sticking with me. When Up is released, it should be pretty good, and make up for the flaws in Party Buffalo. If you’d like to follow the project, you can find its GitHub page here: https://github.com/landr0id/Up. You can also follow me on Twitter (@landr0id) if you’d like. And yes, that picture is of me in a fur coat.

You can grab the latest version here: http://clkxu5.com/drivexplore/Party%20Buffalo.exe

This update is recommended.

Because Mocha Said So…

OS X status:

  • Disks untested (can’t figure out how to escalate privileges)
  • Logical disk (USB/drives with a /Xbox360 folder) reading done, have not worked on writing (see “General”)
Windows:
  • Logical and physical disk reading working, have not worked on writing (see the “General” section)
  • Annoyances with UTF-16 v UTF-32 encoding: check
Linux:
  • Untested, should work the same as OS X
General:
  • Device file stream in progress (haven’t tested all of it, but it appears to work)
  • Need to work on file copying/writing (aka extracting/injecting)

This is NOT Party Buffalo, this is a completely new application.  It’s filed on Party Buffalo because this is its predecessor.  Sign up and comment if you would like to ask questions (I turned off commenting for non-registered users since I had about 800 spam comments)

Also, thanks to kiwi for hosting me.

[Probably Final] Party Buffalo Dev Update

It’s been a loooong time since an update. I’m not going to push this update out because to be quite honest, I don’t have any idea what it fixes from stuff in the past.  I KNOW this update fixes some issues with streams (makes them more proper), and fixes an issue with development kit hard drives not loading properly (lots of empty files and stuff).  Beyond that, I have no clue.  To be quite honest I haven’t even looked at the source since around September when I posted the videos about the filesystem driver (which I dropped due to issues with the Dokan library being a little bitch and thinking I gave it an error when I didn’t.  Maybe I threw an exception somewhere that I didn’t catch or something.  I have no idea.)

Currently I’m working on a bigger (I guess?) and more exciting project as it will be a huge learning experience for me, and I’ll come out with more details about that later.  For now, I’ll just say this… It’s a god damn cross-platform device explorer that probably won’t be done for a while.  I expect to move domains here soon to something that I’d like to show a possible employer, so check back about once a month (hahaha don’t even know if anyone’s reading this right now) to see if I post any news about that.

Without further ado, here’s the download link: http://clkxu5.com/pb_final_maybe_no_clue.zip

Remember, it’s a development build and so the DLL’s aren’t merged, the latest news doesn’t show, it doesn’t check for updates, and there’s some sort of weird exception handling that I can’t remember.  Jesus, I’m 16 with Alzheimer’s already.

 

PS: 

 

FATX Driver for Windows

So this is something I got done at about 10:19 this morning after not much work…

 

This isn’t a native driver though.  Since I’m not in the mood to port my FATX libraries to C++ (at this moment in time!) I looked for an alternative solution and found the Dokan library, which lets you make user-level file system drivers REALLY easily in .NET and C++.  Right now it only shows the “FATX Drives” thing in My Computer then lists out devices (I need to figure out a good strategy to just list the devices in My Computer).  There’s nothing beyond that since I’ve got class in about… 30 minutes and I’m about to leave my house, but hopefully I’ll have something good going by the end of the night!

TO DO:

  • Add writing support to my FatxFileStream class (and optimize it)
  • Add subdir/file support (lol)
  • Accurate disk space calculation (very easy, didn’t have the time to do it)
  • Friendlier UI versus the console app I have running right now.
There’s really not much to do besides that!  Stay tuned…

Party Buffalo 2.0.0.9 Update

So it’s been a while since my last blog post.  I’m now a little older, a little wiser, and I’m starting to get hair in really weird places, man (for those of you not getting the reference, see: http://www.imdb.com/title/tt0108525/combined).  Let’s get down to the update.  As some of you may have noticed in the changelog, there was a rather interesting part to it…

IMPORTANT: IF YOU ARE HAVING ERRORS ABOUT A BAD FAT CHAIN, THIS NEW VERSION WILL MARK THE FILE OR FOLDER AS DELETED.  This is to avoid other possible errors!  The exception will be thrown and then you will be REQUIRED to reload your drive!  To make an attempt to recover the data, go to Drive>Loading Options>File Recovery Mode and make your attempt!  I figured this is a much easier method than me going in person-by-person and fixing this issue.  The FAT chain may have become corrupt when trying to inject a file that’s already in use!

So… here’s my reasoning for this; I was getting some users saying that they were getting a bad FAT error, and this keeps the user from loading their drive since Party Buffalo’s a piece of shit and loads the entire drive at once because I don’t know how to code.  This also causes issues with deleting folders, since it will never be deleted unless the file is fixed, or deleted first (I guess those kind of go hand-in-hand).  Since not everyone knows how to:

  • Open their drive in a hex editor
  • Find the entry offset
  • Get the FAT chain
  • (other FATX-related shit goes here)
I’ve just decided it’d be easier, and a better use of time if I make it delete that entry, allowing the user to load their drive and if they want the data back, use the File Recovery Mode to attempt to recover it (although I’ve said from the beginning, make some god damn backups of your drives).  The next part of the changelog goes along with this.
Checks to see if the file is in use BEFORE doing ANYTHING in the CreateNewFile() method
That’s just a precaution to make sure that nothing retarded happens and we’re not wasting time.  Why didn’t I do this from the beginning?  I don’t know.
MOVING ON
Fixes (again) disabling the check for updates thing
A user emailed me about this one, and it was pretty retarded.  Pretty simple fix, pretty self-explanatory.
Adds support for dev kit hard drives
Yep, it does.  The dev kit drives will show up in the device selector as “Dev Kit HDD” or something like that.  The reason why this was just put in now is because I’ve got a couple dev kits to test that stuff out on, so why the hell not?  I think I forgot to add the compatibility partition though, so I’m pretty dumb.

Cache filename prefixes

So, being bored around 12:30 AM I determined that I didn’t like how I didn’t know exactly what I was looking at in the cache folder and decided to take action about it.  After looking around XAM a little bit, I found the prefixes and their “labels” so to speak, and made Party Buffalo load them.

Here’s the outcome:

Now with more cache

Now with more cache

 

It displays it where it would normally display the STFS content title, but since they’re not STFS packages we don’t have to worry about that.  Maybe I’ll rename that column now?  I don’t know, but for those of you people using my DLL’s that want to take advantage of it the way I have it implemented now isn’t really ideal…

 

    public enum Prefixes
    {
        XlfsUploader,
        NuiHiveSetting,
        NuiTroubleShooter,
        NuiBiometric,
        Dns, // LOOK UP
        ValidCert,
        CertStorage,
        AvatarGamerTitle,
        ProfileSettings,
        QosHistory,
        Dns2, // LOOK UP
        GameTitle,
        TitleUpdate,
        TitleName,
        Tickets,
        SystemUpdate,
        SPA,
        GamerTitle,
        GameInvite,
        GamerTag,
        FriendMuteList,
        DashboardApp,
        CustomGamerTile,
        AchievementTile,
    }

    public static class CacheFilePrefixes
    {
        public static string[] CachePrefixes = 
        {
            "XL", "NH", "TS", "NB", "NS", "VC",
            "CA", "AV", "PS", "QH", "MB", "TT",
            "TU", "TN", "TK", "SU", "SP", "GT",
            "GI", "GA", "FM", "DA", "CT", "AT",
        };

        public static string[] PrefixNames =
        {
            "XLFS Uploader", "NUI Hive Setting", "NUI Troubleshooter", "NUI Biometric", "", "Valid Cert",
            "Cert Storage", "Avatar Gamer Title", "Profile Settings", "QoS History", "", "Game Title",
            "Title Update", "Title Name", "Tickets", "System Update", "SPA", "Gamer Title",
            "Game Invite", "Gamertag", "Friend Mute List", "Dashboard App", "Custom Gamer Tile", "Achieveemnt Tile",
        };

        public static string GetPrefix(Prefixes Prefix)
        {
            return CachePrefixes[(int)Prefix];
        }

        public static string GetPrefixName(Prefixes Prefix)
        {
            return PrefixNames[(int)Prefix];
        }
    }

 

I’ll have to work on that.