IDK if GitHub sends you notifications when someone forks your project, but I'm the same guy who forked VSOI for PSTV users.

Aside from thanking you, I wanted to also inform you that the new feature you introduced on version 2.0 isn't working as intended. What I'm talking about is the feature that restores app icon layout upon second run.

I can't remember the full details of what happened as the 10 second timer was too quick for me to read (consider implementing a log file system? I suppose I could have also increased the timer on the VSOI-PSTV fork for testing purposes), but basically the result was this:
1) Upon first run everything works fine-- backups are made properly
2) Upon second run it backs up the Near (or in my case, the Parental Controls) app a second time, meaning the original system app is destroyed and replaced with a backup of VitaShell.

Fortunately I just by chance already had a backup of the Parental Controls app (and the Near app, for that matter; PSTV still has Near, it just doesn't show up in the live area), so I could restore it without any issues. But this has opened my eyes a little, and I think I'll be backing up all my system apps just in case something else goes wrong (like if I implement any alternative features I have listed in my readme.md).

Personally I think you could at least partially resolve this problem with one of two different solutions (or a combination of the two):

If system app backup already exists, then do not overwrite existing backup (via either skipping backup or appending a number to the end of the filename)

On (first? or any?) run, backup system app eboot to a folder named NPXS10### in ux0:data/ (where ### is the correct number for the system app; Near is NPXS10000, Parental Controls is NPXS10094) and refuse to overwrite it if it exists on a second run, then immediately following this backup, make a backup of the eboot to ux0:data/ and overwrite any existing eboot. If it will work the way I imagine it would (and assuming the user has not modified the system app already), the eboot in the NPXS10### folder in ux0:data/ should ALWAYS be the system app's eboot and thus will be safely tucked away. Then the second copy will be a fresh backup of whatever eboot was in the original NPXS10### folder from vs0:app/ at the time of backup.

Forgive me if my ideas here are garbage-- I'll be the first to admit I'm a terrible coder and have only formally studied Java, but I'm at least familiar with programming concepts.

As for a new feature for VSOI, consider migrating the backups to ux0:data/VSOI/ instead of ux0:data/ just for the sake of cleanliness. I tried to implement that myself but ran into an error where it wouldn't back up any of the files it was supposed to (I assume because I didn't create the VSOI-PSTV folder before attempting to back up the files). As terrible of a coder as I am, that much I'm sure I could eventually figure out.

IDK if GitHub sends you notifications when someone forks your project, but I'm the same guy who forked VSOI for PSTV users.

Aside from thanking you, I wanted to also inform you that the new feature you introduced on version 2.0 isn't working as intended. What I'm talking about is the feature that restores app icon layout upon second run.

I can't remember the full details of what happened as the 10 second timer was too quick for me to read (consider implementing a log file system? I suppose I could have also increased the timer on the VSOI-PSTV fork for testing purposes), but basically the result was this:
1) Upon first run everything works fine-- backups are made properly
2) Upon second run it backs up the Near (or in my case, the Parental Controls) app a second time, meaning the original system app is destroyed and replaced with a backup of VitaShell.

Fortunately I just by chance already had a backup of the Parental Controls app (and the Near app, for that matter; PSTV still has Near, it just doesn't show up in the live area), so I could restore it without any issues. But this has opened my eyes a little, and I think I'll be backing up all my system apps just in case something else goes wrong (like if I implement any alternative features I have listed in my readme.md).

Personally I think you could at least partially resolve this problem with one of two different solutions (or a combination of the two):

If system app backup already exists, then do not overwrite existing backup (via either skipping backup or appending a number to the end of the filename)

On (first? or any?) run, backup system app eboot to a folder named NPXS10### in ux0:data/ (where ### is the correct number for the system app; Near is NPXS10000, Parental Controls is NPXS10094) and refuse to overwrite it if it exists on a second run, then immediately following this backup, make a backup of the eboot to ux0:data/ and overwrite any existing eboot. If it will work the way I imagine it would (and assuming the user has not modified the system app already), the eboot in the NPXS10### folder in ux0:data/ should ALWAYS be the system app's eboot and thus will be safely tucked away. Then the second copy will be a fresh backup of whatever eboot was in the original NPXS10### folder from vs0:app/ at the time of backup.

Forgive me if my ideas here are garbage-- I'll be the first to admit I'm a terrible coder and have only formally studied Java, but I'm at least familiar with programming concepts.

As for a new feature for VSOI, consider migrating the backups to ux0:data/VSOI/ instead of ux0:data/ just for the sake of cleanliness. I tried to implement that myself but ran into an error where it wouldn't back up any of the files it was supposed to (I assume because I didn't create the VSOI-PSTV folder before attempting to back up the files). As terrible of a coder as I am, that much I'm sure I could eventually figure out.

Ah, I know it doesn't work, I was sure the one reddit comment claiming it did was from someone who didn't know it for sure. I've removed it already from my local repository, ended up not pushing it. I'll be updating VSOI when I can, am a bit busy now. The initial release was pretty much just to get something that worked ready.

What I intended to do with VSOI was to get a one-click solution for Near-replacement. I'll also be working on HBI when I can, cleaning up the code and whatnot.

My local repo also made it so the second run restores any existing backup files, I'll push it when I can and make a new release.

Hi, angry user here, like andoryuu3 I thought running it a second time would restore my near, now it is deleted and I'm not sure I have a backup.

Please update it, remove it or at least warn users before they download the app!

Remove it? What? Because *you* assumed it did something it doesn't say on the readme? I don't think so. As I said, this is a one-click utility to replace Near with VitaShell. I'm sorry, but if there's anyone you should be angry at is yourself for assuming that. While I may or may not update the application to restore a backup and/or not replace the existing backup if it exists, I made this application for myself first and foremost, and I owe you nothing.

Also, just grab yourself a working Near eboot, replace it manually and you should be fine. If you compile the code available on my repository, you should have that second run behaviour you want. I never released a version containing that, but it's in the code and you can compile it yourself.