DSL Embedded :: Problems with filetool.lst



Quote (pr0f3550r @ Feb. 22 2006,07:58)
Quote (roberts @ Feb. 21 2006,15:37)
Why would anyone expect a backup to occur when they have aborted a virtual machine?

Why not? At the end of the day a virtual machine needs not be shutdown properly.

Actually pr0f3550r, it does need to be shutdown properly for the save to be complete.  If you think about it, when you saved the backup you saved it to a virtual drive.  That's great, but when does the virtual drive get saved?  When you close the emulator correctly.  So if you close the system down incorrectly or incompletely, the virtual drive never gets saved and your backup is lost.
Quote (cbagger01 @ Feb. 23 2006,12:28)
I may be wrong, but if you push the "BACKUP" button on the Backup/Restore tool, does it immediately back up your files?

No, it doesn't.

@clacker

What you say makes sense and I am just experimenting.
However the funny thing is that if I run:
sudo filetool.sh backup

when I boot again, some files sre backed up and some not.
Looks like the proper shutdown backs up all the /home/dsl directory, but the manual backup doesn't.

While I'm here I have noticed that the backup and restore process done from the *.iso image works much better than the standard embedded, that keeps on corrupting my dsl directory...
Sorry, I cannot buy into this argument.
Pushing the Backup button calls sudo filetool.sh
So does the powerdown.sh, there is no difference between using the GUI or shutdown. Don't believe it, read the scripts!
There is only one common backup/restore script which is used across all versions of DSL.

You should at least post the size of virtual hard drive (using mount) and the size of your backup.tar.gz (using ls -l) and finally post the output of your /etc/fstab and /etc/mtab.

What may be happening here is:
1. You have exceeded the size of the virtual drive.
   You can test this adding something to the filetool.lst
   Perform the backup and then tar -ztvf and see that it is there.
2. You may have doubly mounted the device.
3. You may be experiencing some Qemu issues with size and possibly order of the append clauses of the -kernel option, similiar to the Linux version of Qemu which I can see the inconsistency.

If the -cdrom option to Qemu solves this, it would be nice to know. Especailly if a size issue is involved.

I am most curious to see the sizes involved here.
We need some way to duplicate your issue.

original here.