What is LaunchELF?
LaunchELF is a file manager program for the PlayStation 2.

The original LaunchELF project was by Mirakichi, who worked on versions prior to v3.41.
After Mirakichi stopped working on LaunchELF, E P and dlanor worked on unofficial LaunchELF (uLaunchELF) up to v4.42d.
Due to real-life commitments, both E P and dlanor have been on a hiatus for quite a few years. Double-unofficial LaunchELF (wLaunchELF) is a new project by AKuHAK and SP193 that continues to bring new updates to our favourite file manager to the PlayStation 2.

The first stable release is slated to be LaunchELF v4.50, to mark the start of a new line of builds. As of today, we are still updating and fixing LaunchELF, so we will appreciate constructive comments and feedback about the quality and functionality of LaunchELF.

While E P and dlanor have not officially declared that they won't be ever coming back to continue work on uLaunchELF, I have decided to create a new thread in order to avoid cluttering their thread with posts regarding new bugs that are caused by the (rather invasive) work on the code.

Retracted addition of padEnd() to CleanUp(). It does not work as intended with the old libpad library. May not be required with the old libpad library either. This may fix pad support in software that do not reboot the IOP.

Replaced timer code with time code from ps2sdk. Also takes care of missing ExitHandler() call within interrupt handler.

Added IOP reboot to ELF loader, for when a HDD-based target is booted. While keeping backward-compatibility with old software (which do not support the HDD unit) by keeping the necessary modules in RAM, it will keep the IOP in a clean and initialized state for newer software that support the HDD unit.

if you press Square on HDL partition - you can load HDL info, if you press Square again - you can unload HDL info (it is needed for renaming HDL partition without reloading HDD manager);

you can expand only PFS partitions;

now uLe support official hdd loading path, after loading he mounts partitions from where it is loading into pfs0:/, so now you can simply load LAUNCHELF.CNF which is placed in the same place as uLe. e.g. hdd0:/__sysconf/FMCB/

now you can load and save configuration files (including ipconfig.dat) from everywhere

you can place LAUNCHELF.CNF in the same folder where is uLe placed

if you inject it in partition header via PATINFO it now tries to read LAUNCHELF.CNF from the root of partition if it is in PFS format. If it is not pfs partition it tries to load it from hdd0:/__sysconf/FMCB/ (specially for l_oliveira)

There seems to be a problem with LaunchELF's VMC functionality. I have not finalized the findings, but right now it is probably better if nobody uses the VMC function of any LaunchELF build to add new files to a VMC image. Regardless if it is a stable version or not.

For now: I believe that there is a long-running glitch in the design of LaunchELF's VMC functionality. In order to make copies of files with exactly the same timestamps (for creation, last modified and last accessed), a chstat() operation is done on all copied files. It is assumed that the device supports it.
chstat() is supported by the VMC device... but it will always update all possible fields. LaunchELF never changes the attr, size and mode fields, and hence never fills them in. As a result, VMC will update these fields to undefined values.

I do not know why it never (visibly) happened earlier. For now, I believe that it got exposed from the November 2016 refactor of LaunchELF to not require two versions of the file I/O library.

Symptoms: copying any file to a VMC image will result in no files/directories being copied correctly. Space will be consumed (and hence lost) and the directory records will be created, but the directory records will have the size and mode fields cleared to 0.Affected versions: the wLaunchELF versions provided in this thread allow the symptoms to be observed. However, all versions of LaunchELF may have this glitch.

Prototype that does not clear the attr, mode and size fields of a VMC file/directory: https://www.sendspace.com/file/xp4rir
If you test this, please let me know if you still cannot add new files to a VMC image without issues.

@sp193 , I was never aware that launch.elf had changed devs that often and that with it came a name change. thank u for that clarification. I had always known it as ulaunch.elf since about 2006 or so which is when I modded my slim ps3. with a new laser, the system is still kicking. though, there r some signs that show its age, the system that is. I'm very glad that this project still has support. I love launch.elf (usuing ulaunch 4.42d). whenever someone wants me to test something, I always test with a disc following by launch.elf whether that's from a disc or a flash drive. I've yet to come across homebrew that didn't work with launch.elf and via disc, so I'm very happy with it. and, of course I had to have pink icons.

@sp193
I followed you to this forum.
I just tested it with a couple of saves/apps/folders.
It works, with sporadic error.
sporadic error:
Every 4-7 time of copying it brings me first a "copy failed", but if i try again, then it copies.
But i have to say, i tried it only on my 64GB sandisk. So no time for now, rest tomorrow....

@sp193 , I was never aware that launch.elf had changed devs that often and that with it came a name change.

Click to expand...

It is an important project with a fairly long history. So I don't think it really "changed" developers that often. It's more like it had a lot of contributors, over the years. I chose to rename it again because I'm making changes without anyone from the previous development team, like how they renamed the project at v3.50.

I just tested it with a couple of saves/apps/folders.
It works, with sporadic error.
sporadic error:
Every 4-7 time of copying it brings me first a "copy failed", but if i try again, then it copies.
But i have to say, i tried it only on my 64GB sandisk. So no time for now, rest tomorrow....

Click to expand...

I think it can be considered as being solved. The original problem would have resulted in a 100% failure rate because the glitch always happens immediately after the copy operation.
So whatever this sporadic problem is, it is probably unrelated. Neither was I able to replicate it.

Thanks for your help on this issue.

BTW, I hope that you didn't use an old image because any image edited with LaunchELF (prior to this test) would have been damaged. Any space consumed, would have been lost forever.
Also, there is a limitation with the current design of the VMC modules; deleted entries cannot be reused. Hence a directory will always grow longer. I haven't determined if MCMAN also has the same limitation, but it would be pretty strange if it did.

As for the inability to get the folder list with Filezilla, I've found that downgrading ps2netfs.irx somehow solves the problem.
I do not know what the last "working" revision of the module is, but here's the old version I used : fs.zip, and I could then retrieve the folder list with Filezilla, as well as with windows explorer...

Regarding the rename functionality, I changed it to fit the documentation for the standard C rename function:

A file cannot be renamed to an existing file.

A file cannot be renamed into a directory.

A directory cannot be renamed into a file.

A directory can be renamed into a directory, if the destination is an empty directory.

Also, the rename() function is now usable for moving files, from a programmer's point-of-view; it can be used to quickly move files around the USB disk without needing to read and write whole files. Right now, LaunchELF does not move files that way, but I'm sure it would make the moving of files quicker.

As for the inability to get the folder list with Filezilla, I've found that downgrading ps2netfs.irx somehow solves the problem.
I do not know what the last "working" revision of the module is, but here's the old version I used : fs.zip, and I could then retrieve the folder list with Filezilla, as well as with windows explorer...

Are you still having those icons though? :| They aren't supposed to be pink.

Click to expand...

yes, but I can't recall how I changed them. I do remember managing to change the icons to blue and green as well. I know it has something to do with the configuration file, because if I have ulaunch elf on burned media, the configuration file fails to load since I don't have one, and the default icon color of yellow is used. I usually load ulaunch elf from the memory card by holding R1, so they're always pink.

yes, but I can't recall how I changed them. I do remember managing to change the icons to blue and green as well. I know it has something to do with the configuration file, because if I have ulaunch elf on burned media, the configuration file fails to load since I don't have one, and the default icon color of yellow is used. I usually load ulaunch elf from the memory card by holding R1, so they're always pink.

Uh, so there were a few booboos that I won't add into the changelog above because they were all introduced by me. But FYI...

LaunchELF build 2017/06/18:

Fixed USB support on disks with no partition table (thumb drives).

Fixed formatting of PFS partitions.

USB disks will only be mounted if they either contain a supported partition (i.e. FAT12/FAT16/FAT32). Mounting the whole disk will no longer be done, unless the disk is deemed to not have a valid MBR.
Previously, it would attempt to mount the disk, even if it had a valid MBR. This also led to cases of USB disks being improperly accessed, if they were formatted with some unsupported filesystem like exFAT.

I didn't find any standard that specified how the operating system can determine whether the disk contains a MBR or a VBR, which both have the same magic value in the exact same position (why???). But I did some experiments with Windows 10, which led me to conclude that Windows will at least check that for every valid (ID is not zero) partition entry:

The starting LBA must not be zero.

The starting LBA must exist within the disk.

There might have been some check against the size of the partition, but I did not manage to identify a pattern.

I didn't find any standard that specified how the operating system can determine whether the disk contains a MBR or a VBR, which both have the same magic value in the exact same position (why???). But I did some experiments with Windows 10, which led me to conclude that Windows will at least check that for every valid partition entry:

The starting LBA must not be zero.

The starting LBA must exist within the disk.

There might have been some check against the size of the partition, but I did not manage to identify a pattern.

Uh, so there were a few booboos that I won't add into the changelog above because they were all introduced by me. But FYI...

LaunchELF build 2017/06/18:

Fixed USB support on disks with no partition table (thumb drives).

Fixed formatting of PFS partitions.

Click to expand...

Ok tested it. Now it seems to work fine....

I have another issue with wLE, or do you say you have enough??
Cause i tested your wLE´s the last days, i tried to test many as i can, and find a bug with "Text Editor".
I edited some files (ScummVM.INI, LAUNCHELF.CNF) on USB and HDD without error.
The "Text Editor" have problems with editing *cfg files. I tried to edit "conf_elm.cfg" from my OPL and ul.cfg from my USBUtil-games on USB and HDD.
When i want to insert a "Return" / "Enter" command in the file, it don´t inserts it (arrow left & arrow down), it only inserts the same letter/number/symbol that is after the coursor.

This bug seems to be long back, cause i tried it with uLE_4.42d too, with the same result....

Thanks. Unfortunately, it doesn't say how to differentiate between a VBR and MBR. It seems like it depends on the type of disk (and I can determine whether the USB disk has removable media or not), but Windows can mount disks regardless of whether it has a VBR or MBR.

Cause i tested your wLE´s the last days, i tried to test many as i can, and find a bug with "Text Editor".
I edited some files (ScummVM.INI, LAUNCHELF.CNF) on USB and HDD without error.
The "Text Editor" have problems with editing *cfg files. I tried to edit "conf_elm.cfg" from my OPL and ul.cfg from my USBUtil-games on USB and HDD.
When i want to insert a "Return" / "Enter" command in the file, it don´t inserts it (arrow left & arrow down), it only inserts the same letter/number/symbol that is after the coursor.

This bug seems to be long back, cause i tried it with uLE_4.42d too, with the same result....

Click to expand...

Thanks for sharing.

BTW, I saw the posts on psx-scene, but didn't write a reply because I wanted to take a look at the stuff first. Unfortunately, I have some important matters to attend to in real life, so no PlayStation 2 stuff for the moment.

There was a problem with my tcpip.h header, which did not share the same values as the other headers from the 2 LWIP ports.
I reckon that this standardization of values should solve the problem.

There was also the workaround by the old ps2ftpd developers, which worked around the getstat/chstat glitch in PFS. Since that glitch was taken care of, I have removed the workaround. This will mean that if anyone does a directory list operation on the HDD unit, file sizes should be displayed.

Here is a small test, for those who were having problems with FTP transfers seizing up randomly with the PS2 still responsive (to controller input): https://www.sendspace.com/file/2xqep6

Changes to LWIP options:

25 -> 32 PBUFs

8 -> 24 input TCPIP API messages (not for TCP/IP, but is used for passing messages to the "TCPIP" thread that handles packet input)

Semaphores are created with the THPRI option

This should also solve the issue with pings failing when the IOP is under heavy load.

Click to expand...

EDIT: Uploading via FTP now works with the 170827 build. I uploaded a few hundred images to the +OPL partition where as before it would time out after one or two at best. Thank you!

Filezilla's caching of remote folder structure does seem to cause issues sometimes, with browsing into a partition on the HDD showing the contents of the previously browsed partition. Leaving the connection idle for a few minutes then browsing again seems to trigger it.
Most of the time manually refreshing the remote pane fixes this, but sometimes even refreshing at each level from root down doesn't help and I need to close and re-open filezilla.