Is there any reason why uLE can't browse PSF partitions on the PS2 HDD such the one of original HDD games or the __system partition ?
It's known they contain valid PSF filesystems yet uLE can't mount them.
Printable View
Is there any reason why uLE can't browse PSF partitions on the PS2 HDD such the one of original HDD games or the __system partition ?
It's known they contain valid PSF filesystems yet uLE can't mount them.
They are not shown as there is no point on mounting this patitions and modify them.
Well, it's my guess, but there isn't really any reason to give user access to this partitions, but you can still browse them through ftp, so I think hiding game partitions when in ftp isn't implemented.
Is there any way of changing the restriction at source level ? (I mean like compile flags ?)Quote:
Originally Posted by suloku
It could be useful for development and maybe backuping of the files.
All official retail stuff is copy protected/bound to hardware serial numbers anyway so copying them to another hard disk will cause them to not work. I just wanted to have access to my files as means of archiving/repair.
With the new breakthrough of breaking the MG encryption it would also be possible to put the boot file with uLE on the __system partition if the user is given access to it.
Thanks for your answer
Are you sure that it is uLE which is responsible for this, and not some Sony filesystem feature.Quote:
Originally Posted by l_oliveira
uLE does need to block various partitions from the FileBrowser, as attempts to browse them as PFS partitions can crash the console. In some cases this even applies to partitions which are flagged as PFS partitions in their attributes. While it is true that uLE is a bit too harsh in blocking most partitions with a "__" prefix, it is not true that this applies to "__system". In fact I browsed inside that partition a moment ago, even though it's not very useful to do that since it's empty.
How sure are you that all original HDD games use fully PFS compatible storage methods ? Have you tested this yourself ?Quote:
It's known they contain valid PSF filesystems yet uLE can't mount them.
Best regards: dlanor
Probably because they return an invalid attribute. Some partitions just won't mount by normal means. If you want full access you can use fsclient after loading PS2Net and you can take your chances. Or if you want you can change the logic of setPartyList() in filer.c and rebuild uLE to allow it to show all partitions within the fileBrowser.Quote:
Originally Posted by l_oliveira
Some of the system partitions can't be mounted at all as I tried just that a longtime ago.Quote:
Originally Posted by l_oliveira
It is implemented in ps2ftpd and has been for many years now. Not in ps2netFS though. I never bothered to monkey with it as I rarely use it.Quote:
Originally Posted by suloku
We have not prepared any such flags but it would be fairly simple to do so, in adding code to change the blocking method. This is currently handled by some 'if' statements of the function 'void setPartyList(void)' in the file "filer.c".Quote:
Originally Posted by l_oliveira
No defense speech is necessary. There is nothing wrong with accessing any files you please on your own equipment, no matter who owns the copyright to those files, unless you've acquired those files illegally, which I always assume not to be the case.Quote:
It could be useful for development and maybe backuping of the files.
All official retail stuff is copy protected/bound to hardware serial numbers anyway so copying them to another hard disk will cause them to not work. I just wanted to have access to my files as means of archiving/repair.
Our only reasons for blocking some partitions from the uLE browser are that access attempts in non-PFS partitions can crash the console, and also that inclusion of all HDL game partitions in the browser list would make all HDD access too slow for practical use on consoles that have many games (and a modern HDD can hold hundreds of them).
And our main reason for blocking all '__' prefixed partitions except those known to be safe, is that some of them are known to cause crashes and there is no safe way of testing for those cases, since the test itself could cause a crash (just as with the CodeBreaker partition).
If you can give us a list of the partitions you want uLE to not block access to, then we will consider modifying the blocking method. But "__system" is NOT currently blocked by uLE, so any problems in accessing it must be due to Sony methods of protecting their secrets. If they have flagged that partition somehow as being inaccessible to the normal drivers, then there is not much we can do about it in uLE sources. Getting around such things would probably require changes in the HDD drivers.Quote:
With the new breakthrough of breaking the MG encryption it would also be possible to put the boot file with uLE on the __system partition if the user is given access to it.
Best regards: dlanor
Firstly thanks for your replies, EP and dlanor.Quote:
Originally Posted by dlanor
While accessing the retail games partitions would be nice and I would appreciate a lot, it's not as important as having access to the __system partition now. As for people with ATAD patchign capable modchips or people with official hard disks can probably now use it as a bootable partition with FreeMcBoot.
EP:
Probably on disks formated with DMS tools, HDLoader or Winhiip (I think this last one doesn't even bother with creating the system partitions) the system partitions will be completely empty. But on my PS2 (I made raw dumps of my partitions to peek inside) and there were quite a bunch of files listed there.
A zip file with the full dump of the files also surfaced a while ago and I have it here. The tools used to make the FreeMcBoot were able to dismantle/decrypt it so it's very likely that a properly crafted freemcboot file placed at the __system partition will boot.
dlanor:
I am sure that all commercial games have at least a small section of their data in a PFS readable format as the browser (And even PSBBN) need to access it to load the boot files. PSBBN goes a step further as it reads a description text file and a JPG image for the title icon instead of the 3Dicon the Browser uses.
Titles can also contain manual or comments for the user.
To retrieve them PSBBN has to access the partitions and look inside.
Thank you for your attention, guys.
Sorry for draging up an old thread but.... Is there a good reason why cdfs isn't accessible via FTP using PS2Net?
I sell a load of used games and have found (at least on the xbox) that the ability to access DVD contents via FTP from a console is a huge help, basically allowing me to see if there's any scratches affecting readability of data on a disc on the actual system and drive/s it's destined for, and not just relying on what some surface scan in a (usually much more powerful) PC drive tells me.
I was hoping there'd be an easy way to do this on the PS2 but I'm not seeing any DVD drive FTP access :( Anyone know the easiest way to do it if it's possible?
The original reason (in the separate FTP server that preceded uLE) was probably just that the server was intended primarily for moving data from a PC to PS2 media, and since CD/DVD are not writable media on the PS2 they were obviously excluded. And no one saw any reason to change this in reimplementing the server for inclusion with LaunchELF.Quote:
Originally Posted by pepsi_max2k
In order to make a decent evaluation of the readability of a disc you will have to read a large part of it's total content, for which the slow FTP speed of this server is unsuitable.Quote:
I sell a load of used games and have found (at least on the xbox) that the ability to access DVD contents via FTP from a console is a huge help, basically allowing me to see if there's any scratches affecting readability of data on a disc on the actual system and drive/s it's destined for, and not just relying on what some surface scan in a (usually much more powerful) PC drive tells me.
The easiest way to test-transfer data from the PS2 CDVD drive to a PC is by copying files/folders from the "cdfs:" device to the "host:" device in the uLE FileBrowser, with some suitable HOST protocol driver running on the PC. (eg: RadHostClient or PS2ClientLoader) This method is so much faster than FTP that you won't ever consider going back to FTP after trying it.Quote:
I was hoping there'd be an easy way to do this on the PS2 but I'm not seeing any DVD drive FTP access :( Anyone know the easiest way to do it if it's possible?
As for adding "cdfs:" device as another pseudofolder in the FTP root, that would obviously be possible, but I still don't see much real motivation for it.
Best regards: dlanor
Thanks. Really the whole disc is what I'd like to test, though I've made do with a PC and nero cd/dvd speed read test for now. I'll deffinately look in to PS2Client Loader etc though. :)