Who deleted my OEM packages from the FTP
 

Someone deleted my OEM packages folder from the FTP, whoever you are fukc you buddy.

Its rude and is wasting bandwidth, leave the folders alone and let the admins handle the cleanup

I agree, I like to remove a lot of the crap in the kitchen. And some OEMs are just easier to tweak the original files rather than rename and initflash over. I know this is not the best practice for redistribution, but it works fine for my own use.

we had a rush of new people join the forums affter the wm6 rom and then verizonguys helmi's kitchen. They wreaked (sp?) havoc on the ftp. Almost all the oems kitchen and other stuff was deleted.
And the password for Apache_Helmi_WM6.rar is "PPCGeeks"

BigJ i have all your oems backed on disk if you want me to upload em let me know.

bmbandit
Most of the oems are in PPCGeeks_OEM.rar

Thanks, I realize this. The main one I have issue with conflicts with the threaded sms. The original file is in the Sys. No big deal can just overwrite after flashing, but just prefer not to waste space.

oh wow, i didnt realize >.<
I would love it if you re-uploaded them, as I dont have them any longer, My hard drive got bad sectors and my kitchen folders on my computer wont open. I put the drive in another computer to pull them off but now when i use them in the kitchen none of them work. Im sure they are all corrupted from the drive but I dont want to retest each one individually.

I went to the FTP this morning to grab them all (good backup) and they were GONE!!!. I laughed, i cried, and remembered I have an older set on my work computer.

so long story short, ya if you have the most recent packages I uploaded that would be fantastic!

Thank you so much for your prompt reply, and I understand why you protected the files now, appreciate the pass, i needed to mod the OEM OPERATORS files (clear transparent gif for carrier and a few reg entries I customize with).

And I see you were a huge participant on this last kitchen, great job. Not at all what im used to but ill figure it out!

Thanks!

I think the password is "ppcgeeks"?

I think it was done more to protect the innocent... and the careless :D

Ok upload complete.

I also have your older oem folder if you want that uploaded to the Older Oems folder.

Is it possible for regular user to delete files on the ftp? I don't know much about using ftp's so i just drag and drop or copy and paste the files which is what I was instructed to do. It just seems odd that a regular user can delete files. Shows my ignorance on the topic I guess lol.

Yes it is possible for user to delete files on the ftp. I had a problem with people deleting my stuff a while back. Ever since then i would make a backup of the apache folder every month or so. Just incase.

You can do the mods outside of the core, by using a personal OEM for the reg settings and the Patches folder for files. Knowing your work, however, I may have to expand on the implementation of how the Patches folder works...let me know if it's inadequate or you have ideas for improving it.

For the curious, I'm encouraging people to not modify the core because it makes upgrades a real pain - for the developer and the user.

Can you expand a bit on how the new patches folder works? Or point me at whatever docs I missed?

It's documented somewhere, but I forget where, so here's the gist of it:

First, if you don't have the patches folder already, you can add it to the 11/07_1 kitchen by createing a Patches folder and adding PatchDir=Patches to your selections.txt file. 11/07_1 distribution is the first ditribution with support for this feature.

It's really easy to use...put any files you want to overwrite core files in it.
BuildOS will copy those files to the ROM right after hive creation (which is why you can't use this method for rgu changes)
Any file that already exists in the ROM will be overwritten.

For RGU changes to core files, the best mechanism is the same as always...make an OEM with a uuid in the ffffff range.

That's all there is to it.

Thanks, seems simple enough.... so for example you could use that to do the PIE .dll patch in rom just by dropping in the .dll in the Patches folder?

simple, eh?

The down side of this approach, which will probably cause me to change a few things, is that you _always_ get the patch applied. This is fine for 90% of the core, but some things you can opt not to include...and the patch shouldn't be applied when you've opted out. I'll try to fix that behaviour for the next release.

Replacing modules is a bit trickier, as the patch must also be a module - you can't replace a module with a file.

Just to expand on the information given in this thread, when you have conflicting registry entries in the RGUs of your kitchen, the one parsed last is the one that will make it into the final rom. By using a UUID starting with f's in the first group of the UUID, your rgu in that package will be parsed towards the end, effectively replacing any conflicting registry entry you want to replace/update.

Another method of updating registry values is by using a minus sign after the opening bracket of the line, but this is not the preferred method in this application, as users may inadvertently remove an entire key when just trying to update one value. The f's naming convention is the way to go.

A UUID is usually assigned randomly or based on the time it was generated or both. In the current variant used, there are 5 versions used.

1. Time-based with unique or random host identifier
2. DCE Security version (with POSIX UIDs)
3. Name-based (MD5 hash)
4. Random
5. Name-based (SHA-1 hash)

You can find out which version is being used by looking at the first digit of the third group. For example, the tools some choose to use include the new oemizer and oem helper. Both tools use random generation, as demonstrated by a25ba3df-785a-4a9e-8dd4-b89d9f519e29. As you can see, the first digit of the third group is a 4, so it is random.

Anyway, this is probably way more than you ever wanted to know about UUIDs and how RGUs are processed and why, but figured I'd throw the information out there for those who care.

Can you elaborate...maybe an example or two? It sounds like your saying if I have
[asdf]
a=1
b=2

and I put this in my rgu:
[-asdf]
b=3
c=4

that I'll end up with
[asdf]
b=3
c=4

instead of
[asdf]
a=1
b=3
c=4

Is that correct?

BigJ - out of curiosity do you have an OEM for the WM6 threaded SMS? If you need the cab let me know.

Yes, and no. It applies to the whole key and isn't able to be used for specific values to the best of my knowledge.

example:

If your package has the following:

The usage is
which removes the whole Parms key and any values contained therein.

That's correct. The hyphen deletes a key--that's it.

I've been wondering how to do that for months! Thanks.

...now I need a CoolApp to try it on...