Restoration from backup failing

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Trying to restore database (generated with encryption)

2. Uploading database, upload flash applet appears to work, prompts me for the 
encryption key.

What is the expected output? What do you see instead?

I expect to see my backed up passwords database. what I see instead is the 
empty passwords database that is making me sad and want to restore from my 
backup in the first place!

What version of the product are you using?
CPassman 2.00b2

On what operating system? With what Browser (IEx, FFx, ...)
Ubuntu 10.0.4 LTS, standard LAMP stack from the 10.0.4 repos.
Using Firefox 11

Please provide any additional information below.

Looking at the /var/log/apache2/error.log I see lines that appear to correspond:

[Mon Feb 13 22:09:17 2012] [error] [client 10.101.13.143] PHP Notice:  
Undefined index: post_id in 
/var/www/cpassman/includes/libraries/uploadify/uploadify.php on line 71
[Mon Feb 13 22:09:17 2012] [error] [client 10.101.13.143] PHP Notice:  
Undefined index: type in 
/var/www/cpassman/includes/libraries/uploadify/uploadify.php on line 81
[Mon Feb 13 22:09:28 2012] [error] [client 10.101.13.143] PHP Warning:  
file(../files/445d6b30e2d866ccfae318f7dcb595ce): failed to open stream: No such 
file or directory in /var/www/cpassman/sources/admin.queries.php on line 264, 
referer: http://hww-cpassman.hogarthww.prv/index.php?page=manage_settings
[Mon Feb 13 22:09:28 2012] [error] [client 10.101.13.143] PHP Warning:  
unlink(../files/445d6b30e2d866ccfae318f7dcb595ce): No such file or directory in 
/var/www/cpassman/sources/admin.queries.php on line 267, referer: 
http://hww-cpassman.hogarthww.prv/index.php?page=manage_settings
[Mon Feb 13 22:09:28 2012] [error] [client 10.101.13.143] PHP Warning:  
Variable passed to each() is not an array or object in 
/var/www/cpassman/sources/admin.queries.php on line 272, referer: 
http://hww-cpassman.hogarthww.prv/index.php?page=manage_settings

What is interesting is that if I go and look in /var/www/cpassman/files I can 
see the database backup I uploaded with a random name, but no sign of the file 
445d6b30e2d866ccfae318f7dcb595ce

ls -alh /var/www/cpassman/files
-rw-r--r-- 1 www-data www-data 329K 2012-02-13 22:09 
097eade2b9f75c5af0377db3ca8c2b6e

Looking at the lines 264 and 272 in admin.queries.php it looks like the error 
is coming from line 259 where the file is defined

        $file = md5($_POST['option']);

This appears to be generating a different number than the filename actually 
given to the file, thus when line 264 tries to read the file into a file array 
it fails and line 272 subsequently cannot make sense of the non existent array.

I'm pretty sure I have successfully restored backups in the past

Original issue reported on code.google.com by spastic...@gmail.com on 13 Feb 2012 at 11:09

[GoogleCodeExporter]

I managed to recreate this issue using the latest release of TeamPass, build on 
a clean install of Ubuntu 10.0.4 LAMP.

The files are still getting uploaded to the files directory but the PHP scripts 
are getting the wrong file name passed to them, the difference is that the 
files are now retain their original file names when they reach the files 
directory. However the PHP scripts are still looking for files with long random 
alphanumeric names and still failing.

I ended up working around this issue on, firstly my test TeamPass installation 
and then on my real CpassMan installation by noting the random file name that 
the PHP code is looking for and, renaming the uploaded file to match this, then 
attempting to restore the same file again. The process generates the same 
(wrong) filename and passes it to the PHP code which tries to open, decrypt and 
restore the db dump. This time however it then finds the file it is expecting 
and the db is restored.

As this is apparently an ongoing issue with TeamPass I'll file this on the 
GitHub issue tracker too.

The strange this is I can remember restoring backups from dumps in the past and 
it worked as expected.
There is some good news, once I got my passwords back I upgraded to TeamPass on 
my real server, which I had been meaning to do for a while but the forced 
downtime gave me the opportunity, thanks for implementing those automated 
backups.

Original comment by spastic...@gmail.com on 14 Feb 2012 at 5:31

[GoogleCodeExporter]

Hi,
I've corrected a bug concerning files management in the next release 2.1.4 and 
maybe the issue you're facing is a consequence of this old bug.

I've done some tests on my actual test base with this (soon released) 2.1.4 and 
I've been able to create the encrypted backup and restoring it without any 
issue.

Please wait until next release, update and tell me.

Original comment by nils.lau...@gmail.com on 15 Feb 2012 at 7:47

[GoogleCodeExporter]

Cheers nils, I'll pull the 2.1.4 code from GitHub and try and recreate in the 
test server. I'll post results here and and on the GitHub issues page.

Original comment by spastic...@gmail.com on 16 Feb 2012 at 4:36