PS2 Filesystem

Hi!

Is there any way to protect icons/directories/partitions for accidental deleting via the (hdd-)osd?
I only found the copy/move protecting bit(s)...
Hiding would be an interesting theme, too.


Rgds.

 

OSD only shows partitions whose name start with PP. so that could be a good start about hidding contents.

 

Thanks for your reply.

Let's talk more about icons and the attributes bits.
:smile-new:


Rgds.

 

Okay, to be more precise:

The normal osd respect the anti deletion bit (not deletable) while the hdd-osd doesn't...
That's strange...


Rgds.

 

Perhaps you could ask SCEI about it...

Here:

https://www.jp.playstation.com/sys/support/formSF/en/

 

A bit off topic, sorry of, but I've a question regarding property flags of PS2MC dirs. Does uLe also respect the anti deletion bit ? I once set my BEEXEC folder to copy forbidden + deletion forbidden + hidden for the fun of it, and uLe returned -5 everytime I tried to remove the folder:nightmare:. So I've dumped my MC, zeroed the flags, rebuilt ECC and flashed it back. Pain in the butt.

Muahahah. I guess they've discontinued the technical assistance of the HDDOSD. If not, then I guess they'll be... reluctant in replying to PAL users of the HDDOSD:livid:.

 

Sarcasm is the key word here. Nuff said.

 

Here i used the evil 4.42 and it deleted all dirs and files without probs.
So it respects nothing...
:friendly_wink:


Rgds.

 

For me it's interesting if that effect is known or not...


Rgds.

 

Oh, there's an ev build of 4.42:tears_of_joy: ? I didn't know lol. I should get out of my cave more often.

 

Yes, I'm sure l_oliveira can give you a link for it... if not, I know it on the forum in a thread or two.. I'm not sure what thread its on... I can upload it and PM you if needed.

Edit: P.S. That HDD Dump I made of KrHACKen's 48bit var. was made upon request by a friend a1200...
I'm sorry if none of the data needed to be uploaded on any sites.
Just say the word and I'll stop adding on to your HDD hack... I'm not trying to get noobs to look at you for help or any of that... I'm sure you all must hate me by now... as I said before sorry, if its doing any bad for you all.

 

mmm i can say you again, but: "It's a sarcasm, Sheldon"

 

AFAIK, no. From what you are experiencing, it seems like MCMAN observes the deletion-forbidden bit, which is why you can't delete it.

The other bits (Hidden etc) are only followed by the OSD as they are used to affect what gets displayed or whatever that can be done to the content with the HDDOSD. I think that this was mentioned somewhere... but I don't remember where (the libmc.h header file in our homebrew PS2SDK?).

And like I've mentioned below in my reply to fresh, this behaviour seems to vary slightly across OSD versions. :topsy_turvy:

uLaunchELF, on the other hand, seems to neglect those bits and tries to do whatever you ask it to. :cool-new:

How can you even compare the normal OSD to the HDDOSD lol... -_-"

The PS2 Memory card uses a different filesystem and different modules from the HDD unit, along with different specifications (and restrictions) from SCEI. Of course it's natural if it behaves differently.

And you didn't say which device you are talking about in this thread. Are you talking about protecting content on your HDD unit or a memory card?

AFAIK the behaviour of the OSD has been changed slightly over the years. If I'm not wrong, the old OSD versions do not respect the copy-prohibited (Or was it delete-prohibited?) bit of content on memory cards, but the newer versions do.

I don't know about the content on the HDD units though, since I have not done in-dept research on that.

 

Ahoy!


I meant the memory card and it's icons.

So, the normal OSD respect the set anti-delete bit.
Same card, same icon with the HDD-OSD is deletable...
:stupid:


I compared the OSD and the HDD-OSD because this is the GUI for the user.
The only difference is to have a HDD or not. With the consumers eyes.
For me it makes no sense why the mc icon is deletable.


Rgds.

 

An explanation is in order:

Sometime around 4.00 and 4.10 uLE started to use the MCMAN and related replacement modules by Jimmikaelkael. That I believe was a preparation for the Virtual Memory Card system it currently support.

At the time we were unaware of why the support to SCPH-10000 was quite finicky but eventually due to SilverBull's work on ODEM and Kermit it was found that the problem was the PS2 Kernel behavior on LoadExecPS2() not wiping memory and cleaning system hooks before launching an ELF. Because the behavior is different on ALL machines released in 2001 (SCPH-30001 being the original reference for most of the homebrew developers) this issue was unknown until sometime around 2010.

That problem broke Jimmikaelkael replacement modules and I had that patched out on the first two versions of hacked uLE. (I needed it working on SCPH-10000 for obvious reasons) so they use ROM0 drivers. That along with SP193's explanation should help making sense of the issue.

4.42 has only the minor changes needed to make it "ev" as it's not a "compatibility test build" (vanilla 4.42 works fine on SCPH-10000 with everything active as it has the needed kernel patch built in). I just changed filer.c and hdd.c for the necessary changes on the behavior.

Also 4.42ev has the same skin bug (where triangle, square, circle and cross become numbers on the screen) that afflicts vanilla 4.42.


And I really hate the way they use the "host:" function on that version. I really feel an urge to strip "host:" and VMC from my ev build.

 

I thought that uLaunchELF started Jimmikaelkael's MCMAN and MCSERV modules at v4.40? It's mentioned in the changelog.

The VMC support seems to have already been there since v3.41.

Oh yea, about that: What problems did you experience? I didn't encounter any problems on my SCPH-10000 units when dealing with uLaunchELF v4.4x... other than some occasional weird freezes that seem to occur when accessing a USB device.

Maybe you should tell them that - if there's a better way, there should be others who share the same view as you. Personally, I hate it whenever uLaunchELF freezes up for about a minute whenever I accidentally select the "host:" option. D:

 

Sorry, I really didn't want to dig the changelog. I'm a bum you know. A lazy bum at that.

But that being added broke SCPH-10000 support when it was added. That's why the first two "ev" build had that "downgraded" back to ROM0 modules.

 

Hey, I didn't mean it that way. :/
I was just surprised that you said that it came out at v4.10 - and I was using 4.40h on purpose because I didn't want to use his MC modules at one point in time.

Ah, I re-read your earlier post, and I think that I was mistaken.

So in other words, the fix for ExecPS2 allowed his modules to be used properlyon the SCPH-10000? That's great.

 

Yes, since kernel patch fixes the problem, 4.42ev has crab-less modules from Jimmi. That's why KrHACKen had problems while using 4.40h and the other guys using 4.42ev had no problems at all...

KrHACKen:

/iop/hdd/apa/src/misc.c

 

Actually, if you look at it carefully, you'll realize that it's not a deliberate restriction. The problem is how the developers of the APA driver made the driver work: If you studied the Sony documentation, opening/mounting a partition requires more parameters than just the partition name: It requires the format, passwords and some other arguments which the homebrew driver doesn't handle and doesn't require.

memcmp() is for comparing two buffers of data - which is a password check in this case. Either pw1 or pw2 contains the partition's password and the other contains the unlocking password entered by the user program.

The homebrew driver fails as it still has this password check despite not requiring a password input from the user program.

I'm thinking of making a fix to the homebrew driver - to allow us to once again specify the password and filesystem type... but I think that some discussion with the other developers is required.