To clear up some confusion for those who don't understand where to put their dev_flash:
X:\cfw\dev_flash <- Place all files from dev_flash here
X:\cfw\dev_flash\cfw <- Empty folder needed for removing the CFW so you don't have to restart the PS3 to test multiple times.
I will eventually just run a recursive search for a dev_flash folder on any device (except dev_flash itself).
LOL at the suggestion that my app could brick a console. Try not to make stuff up when posting, especially when you don't know what you're talking about.
I have a PS3, I've even posted a small library for it already and a few other apps. I simply don't have access to mine until Monday. Don't make baseless assumptions.
Then LoL back to you... It was just an idea of what could happen... Remember that PsP emulator??
Anyway, apps should run at least ONCE before make it public. I don't know any dev who give stuff to public without testing!
And one last thing, i respect your work and efford but test it anyway next time.
We don't even have permanent write access to the PS3's firmware right now, I couldn't write a bricking app if I tried.
Obviously I'd have tested it if I had the chance, but I don't until monday. The source is extremely simple, it should work anyway, so I see no problem in releasing it.
I wouldn't release toilet paper before i test it myself. Seriously , even if it's simple and could not brick something you need to verify your app before release.
It IS very simple. There's no reason that at least the mounting part shouldn't work.
I'm not sure why it's not working for you, but I know that with at least syscall35 there is no problem in mapping dev_flash, I've tested simply mounting usb003\cfw\dev_flash to dev_flash and it worked perfectly. Are you referring to using syscall8 to mount dev_Flash?
You said you didn't test it and now you say you did. I actually didn't because I don't need to (I have a working solution with configurable paths, etc).
The problem was that if you use PL3 to redirect /dev_flash to /1234_456 you also get /dev_flash2 and /dev_flash3 redirected to /1234_456.
It is possible that the payload I was using had issues (I reverted to hermes4b) but one flavor of the PL3 implementation didn't work as expected.
I mean it WORKED by replacing the table and /dev_flash with the new path, but one has to take care for other flashes because they share the SAME names (up to the 2/3).
You said you didn't test it and now you say you did. I actually didn't because I don't need to (I have a working solution with configurable paths, etc).
The problem was that if you use PL3 to redirect /dev_flash to /1234_456 you also get /dev_flash2 and /dev_flash3 redirected to /1234_456.
It is possible that the payload I was using had issues (I reverted to hermes4b) but one flavor of the PL3 implementation didn't work as expected.
I mean it WORKED by replacing the table and /dev_flash with the new path, but one has to take care for other flashes because they share the SAME names (up to the 2/3).
Forgive me if this is wrong - i've not done any work on PS3 or linux coding and don't know much about the syscalls etc but...
Isn't this simply a case of the string that is being matched?
If the syscall used to replace the path isn't specific enough then "/dev_flash" could match with "/dev_flash", "/dev_flash2" and "/dev_flash3" (Proof of this would be if you replaced "/dev_flash" with "/test" and found that flash 2 ended up being "/test2")
So surely the all round solution would be to replace the path "/dev_flash/" as it is more specific and would only match with "/dev_flash/" - it won't match with "/dev_flash2/" ?
Maybe i just missed the point entirely - but being a windows programmer i wouldn't be at all suprised!
(I'm assuming the syscall usage is kinda like a string Replacement) ?
p.s. That is of course assuming /" isn't some kind of escape character!
You said you didn't test it and now you say you did. I actually didn't because I don't need to (I have a working solution with configurable paths, etc).
The problem was that if you use PL3 to redirect /dev_flash to /1234_456 you also get /dev_flash2 and /dev_flash3 redirected to /1234_456.
It is possible that the payload I was using had issues (I reverted to hermes4b) but one flavor of the PL3 implementation didn't work as expected.
I mean it WORKED by replacing the table and /dev_flash with the new path, but one has to take care for other flashes because they share the SAME names (up to the 2/3).
I never said I tested this app, I said I tested mounting dev_flash from usb003.
Originally Posted by PSPSwampy
Forgive me if this is wrong - i've not done any work on PS3 or linux coding and don't know much about the syscalls etc but...
Isn't this simply a case of the string that is being matched?
If the syscall used to replace the path isn't specific enough then "/dev_flash" could match with "/dev_flash", "/dev_flash2" and "/dev_flash3" (Proof of this would be if you replaced "/dev_flash" with "/test" and found that flash 2 ended up being "/test2")
So surely the all round solution would be to replace the path "/dev_flash/" as it is more specific and would only match with "/dev_flash/" - it won't match with "/dev_flash2/" ?
Maybe i just missed the point entirely - but being a windows programmer i wouldn't be at all suprised!
(I'm assuming the syscall usage is kinda like a string Replacement) ?
p.s. That is of course assuming /" isn't some kind of escape character!
You're absolutely right. As I was reading dean's last post I recalled a conversation I had with KaKaRoToKS and he told me the following:
Originally Posted by KaKaRoToKS
and no, it doesn't support wildcards, but you could map /dev/path/ICO to replace all ICO* files..
The Yes/No question thread - 3h ago 
Originally Posted by n4ru
Reply With Quote
