Hello,
After releasing a GUI for hdl_dump for Mac OS X, I'm planning to do the same for ps2client, with the first goal of releasing something to communicate with SMS and ULE.
But I can't make my elflist.txt to work. If I put on it something like :
/Volumes/Media/Movies
but I can't see anything in SMS or ULE.
If I put this :
/
I can see / as a file, and SMS thinks it's a movie and try to open it as this, instead of a directory...
Any ps2client users on OS X around ? Or even linux users ?
Is elflist.txt read by ps2client or SMS/ULE ?
One last question : where can I found the latest version of ps2client ? I've seen version 3 binaries for windows, but not the source code.
Thanks in advance for helping the (very) small Mac community !
ps2client on Mac OS X
The client only responds to commands from the user and requests from the PS2. So, SMS/ULE would be the one trying to open the file. Are you sure its trying to read from host:?
Also, the source for v3 is in the subversion repository (svn://svn.ps2dev.org/ps2/trunk/ps2client), or on my site (http://dev.oopo.net/files/ps2client-3.0.0.tgz).
Also, the source for v3 is in the subversion repository (svn://svn.ps2dev.org/ps2/trunk/ps2client), or on my site (http://dev.oopo.net/files/ps2client-3.0.0.tgz).
Re: ps2client on Mac OS X
It's read by SMS/uLE, and this problem is mostly my fault, since I wrote the original code for doing it in both those programs. At present it only works with backslash used as path separator, since that's all I had available for testing.Yoc wrote:Hello,
After releasing a GUI for hdl_dump for Mac OS X, I'm planning to do the same for ps2client, with the first goal of releasing something to communicate with SMS and ULE.
But I can't make my elflist.txt to work. If I put on it something like :
/Volumes/Media/Movies
but I can't see anything in SMS or ULE.
If I put this :
/
I can see / as a file, and SMS thinks it's a movie and try to open it as this, instead of a directory...
Any ps2client users on OS X around ? Or even linux users ?
Is elflist.txt read by ps2client or SMS/ULE ?
This problem affects the path handling in two different ways. I'ts not just for paths being read from "elflist.txt", but it also affects pathnames constructed at the PS2 end as result of selecting files/folders in the browsers of SMS and uLE (and the latter has to handle folders recursively for some commands). Those paths too will contain backslashes after they've been 'translated' for sending to ps2client. So fixing this is not just a simple one-place patch, I'm afraid. It affects lots of different routines.
It can also be fixed at the client end though, by making ps2client accept '\' as separator (even though it's not the native separator of your OS), and also using it consistently in "elflist.txt".
Perhaps I'm being selfish here, but I honestly think this would be the simpler solution.
Btw:
If you want 'Rename' to work with uLE, remember to use a version of ps2client that includes the "fioIoctl" subfunction I added to implement that ability. You can get the sources for it in the uLaunchELF release thread at PS2-Scene. (That's just a Win32 release though, so you'll need to recompile it yourself. (Possibly after tons of adaption :( ))
Best regards: dlanor
When ps2client opens a file, it doesn't 'accept' one type of slash or the other - it just passes it on (relatively) unchanged to the open() call provided by the local system. There really isn't anything to change as it was kept as simple as possible for reasons like this.
BTW, could you pass along a patch or a link to the source so this magic 'fioctl' function can possibly be included in ps2client proper?
BTW, could you pass along a patch or a link to the source so this magic 'fioctl' function can possibly be included in ps2client proper?
I know, but when host: is used by an application like uLaunchELF, that manipulates path strings depending on user selections in a browser GUI, we get some odd problems.ooPo wrote:When ps2client opens a file, it doesn't 'accept' one type of slash or the other - it just passes it on (relatively) unchanged to the open() call provided by the local system. There really isn't anything to change as it was kept as simple as possible for reasons like this.
A program like this needs to use the 'native' path separator of the system it's running on in the GUI, but in interactions with the HOST driver it needs to use paths acceptable to the host system, even though that system and its standards are unknown to the application.
I had to choose some method of 'translating' between local path strings and host path strings, and since most uLaunchELF users have Windows I chose to use backslash as separator for host strings. I wanted to make it compatible with other systems too, but I didn't see a good way of doing it.
That is why I suggested moving this responsibility to the only program involved in this communication that also knows the standards of the host system, since it (ps2client I mean) has been compiled for that system, and can include patches specific to it.
There's nothing very magic or fancy about it. When this fioIoctl call is used, its argument is simply used as new name to replace the name of the file or folder specified by the most recent fioOpen or fioDopen call, provided of course that the file descriptor used also matches that (otherwise there's an error code).BTW, could you pass along a patch or a link to the source so this magic 'fioctl' function can possibly be included in ps2client proper?
A more elegant way would have been to extend some existing struct to save the name there, specific for each opened file/dir, to allow more 'async' use of this feature, but I didn't want to complicate matters needlessly. The current method does what we needed it for, so I let it go at that. But feel free to improve on it, please.
Anyway, here's the URL to the main release thread of uLaunchELF:
http://ps2-scene.org/forums/showthread.php?t=37242
The first post in that thread always contains the latest version of uLaunchELF in one attached ZIP, and the recommended PS2Client version (for Win32) in another attached ZIP. Both those ZIPs include full sources.
Best regard: dlanor
So how can we fix this.....
This seems to have hit a dead end, this is an issue for linux users. Say you're using ps2client with SMS, for example, you cannot map your file locations with elflist.txt path entries. Only the files that are located in the ps2client/bin location where the ps2client binary is started can be accessed. In essence the elflist.txt is useless.
I would try RadHostClient but the linux binary does not execute on the Power PC arch, so without installing wine and running the windows exe, this is my only option.
Thoughts?
I would try RadHostClient but the linux binary does not execute on the Power PC arch, so without installing wine and running the windows exe, this is my only option.
Thoughts?
the problem with this.. apart from the "load ps2client in the dir you have the content in" if i loaded ps2client in the dir /home/morphix/movies i CANNOT access files in subdirs because it just gives a "segmentation fault" error. For it to work properly.. every file i want to use with SMS.. i would have to start ps2client in that directory. Thats pretty stupid and annoying, surely there is a fix for ps2clients source code?
Apparently someone did post some patch somewhere :) But the sites where it could be found, were all disabled for some reason...
Anyway, I played around with the code a bit myself, and finally came up with a working version. I suck at C coding, so no guarantees :), but here it works.
The patched version can be found here:
http://stuff.nieko.net/ps2link.c
(Note that this is a patched file for version 2.0.0.)
The idea is that the stat()-command (for getting fileinfo I believe) was executed in the wrong directory.
I didn't use elflist.txt anywhere though, I just started it using `ps2client gsexec` in the proper directory.
Anyway, I played around with the code a bit myself, and finally came up with a working version. I suck at C coding, so no guarantees :), but here it works.
The patched version can be found here:
http://stuff.nieko.net/ps2link.c
(Note that this is a patched file for version 2.0.0.)
The idea is that the stat()-command (for getting fileinfo I believe) was executed in the wrong directory.
I didn't use elflist.txt anywhere though, I just started it using `ps2client gsexec` in the proper directory.
I did have been able to complete the first usable OS X GUI for ps2client, you can download it here :
http://xdumb.free.fr/downloads/ps2XClient0.5.zip
You can change the ps2client binary inside the ressources of the application package if you like.
How the app works :
- you drag and drop files/folder into the main window
- sym links are created inside the folder ~/.ps2XClient/
- ps2client is launched from this folder.
I tried with the patch you send me by mail nieko, but ULE (and Crystal Chips BM) still doesn't work (SMS works like a charm). When you say that you finally came up with a working version, you mean with ULE ?? I can launch ELF if they are inside ~/.ps2XClient/ but can't go inside sub directories.
http://xdumb.free.fr/downloads/ps2XClient0.5.zip
You can change the ps2client binary inside the ressources of the application package if you like.
How the app works :
- you drag and drop files/folder into the main window
- sym links are created inside the folder ~/.ps2XClient/
- ps2client is launched from this folder.
I tried with the patch you send me by mail nieko, but ULE (and Crystal Chips BM) still doesn't work (SMS works like a charm). When you say that you finally came up with a working version, you mean with ULE ?? I can launch ELF if they are inside ~/.ps2XClient/ but can't go inside sub directories.