Notices

v0.54 didn't?

nope...............

Wait, so v0.54 wouldn't -find- your files?

edit:
No, of course it wouldn't. I managed to make a mistake when I was searching and replacing, so it was looking somewhere completely nonexistant for the files.
V0.55-1, coming right up...

ooooooooyeah!

Ok, V0.55 is now up on my website, and it's in the autobuilder queue.

In this version, I:
1. Fixed a glitch preventing restoring anything(files couldn't be found).
2. Fixed both SSH and USB Console modes: Now, you can login with the root password set when you installed SSH, or set it via "passwd" as root.
Note: SFTP may not work, so you may have to transfer files by copying them via USB mass storage for now.
3. Improved streamlining; if everything goes well it will restore both backups without waiting for input.

Edit: Actually, wait a bit. I also introduced a small glitch where you can't see the path of the file you are going to restore, so I'll fix that in 0.55-2 and reupload.

v0.55 sees my same backup files

"Edit: Actually, wait a bit. I also introduced a small glitch where you can't see the path of the file you are going to restore.... "
^^^^ was gonna mention this

noice

*sigh*, it's taking a bit longer than I thought. I'm trying to use a little script to word-wrap that line, so it doesn't go outside of the white area for esthetics purposes. Only problem is, I get -nothing- but a blank line.
I know the script does it's job under test conditions, so why not now?

Edit:
Oop, found it. I was using "expr substr ..." which works fine if you -have- an excecutable named expr. Adding a symlink to busybox(or using "busybox expr substr...") fixed the problem.
Uploading in a bit.

OK, version 0.56-1 has been uploaded which has fixed all known glitches.
It's availaible from my website, or via Extras-Devel(soon).
Go test it out, all!

yoink.............

Edit: works a treat mate (in practice)..
finds files and shows path.
will do proper recover later tonight....

THANKS

Even if it seems to be solved to use the system's password here's my comment on that.

Both variants have their pros and cons. Using a default password will work even if rootfs is not readable or /etc/passwd is messed up (given that backupmenu will start at all when rootfs is broken). Downside is that you have to remember that password too and everybody who knows this app or searches this forum will also know the password. Using the system password is way more secure and user can always set a new password within running system. But broken rootfs or similar would also break this access to the device.

So here's my suggestion: use both of it! Give a default password that will be used if no password from system can be read. As long as rootfs is readable the system's root password will be used. In other case the "hard coded" password will be used. A short message indicating which password is active can be presented after enabling sshd.

Another improvement might be an option for the user to set the default password to some own string. Something similar like passwd command which updates backupmenu's password.