gnomevfs.NotFoundError even when the "test" works in remote backup site

[Christopher Barrington-Leigh]

Binary package hint: sbackup

I enter a remote ssh site for the backup (using version 0.10-1) and get a green light. I can ssh from a shell to the site no problem. But the backup fails with (two cases shown below, one with a colon, one without, in the ssh url):

Date: Mon, 23 Oct 2006 12:00:05 -0700 (PDT)
From: Cron Daemon <root@cpbl-laptop>
To: root@cpbl-laptop
Subject: Cron <root@cpbl-laptop> if [ -x /usr/sbin/sbackupd ]; then
    /usr/sbin/sbackupd; fi;

I: Securing permissions at:
ssh://cpbl:<email address hidden>/homegrad/cpbl/private/backup/2006-10-1
2_12.00.13.115222.cpbl-laptop.inc
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 404, in ?
    upgrader.upgrade_target( target, purge )
  File "/usr/sbin/upgrade_backups.py", line 60, in upgrade_target
    self.upgrade_tdir( target+"/"+adir )
  File "/usr/sbin/upgrade_backups.py", line 78, in upgrade_tdir
    v = self.openfile( tdir + "/ver" )
  File "/usr/sbin/upgrade_backups.py", line 307, in openfile
    return gnomevfs.open( uri, 1 )
gnomevfs.NotFoundError: File not found

Date: Mon, 23 Oct 2006 12:08:04 -0700 (PDT)
From: Cron Daemon <root@cpbl-laptop>
To: root@cpbl-laptop
Subject: Cron <root@cpbl-laptop> if [ -x /usr/sbin/sbackupd ]; then
    /usr/sbin/sbackupd; fi;

I: Securing permissions at:
ssh://cpbl:<email address hidden>:/homegrad/cpbl/private/backup/2006-10-
12_12.00.13.115222.cpbl-laptop.inc
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 404, in ?
    upgrader.upgrade_target( target, purge )
  File "/usr/sbin/upgrade_backups.py", line 60, in upgrade_target
    self.upgrade_tdir( target+"/"+adir )
  File "/usr/sbin/upgrade_backups.py", line 78, in upgrade_tdir
    v = self.openfile( tdir + "/ver" )
  File "/usr/sbin/upgrade_backups.py", line 307, in openfile
    return gnomevfs.open( uri, 1 )
gnomevfs.NotFoundError: File not found

[Sasha Kovar (notalx)]

I have the identical problem. It broke for me in Dec 06. Fiesty's 0.10.3-0.1 version has the same problem. Version 0.9-1 has a different, likely similar problem. 0.8-1 seems to be working ok, possibly because it does not need to do the work that upgrade_backups.py is performing. Haven't looked deeply at the code.

[mNeo (maverickneo)]

I also see the same problem:

jamesbond@jamesbond-laptop:~$ sudo /usr/sbin/sbackupd
Password:
I: Securing permissions at: ssh://jamesbond:<email address hidden>/home/jamesbond/backup/2007-04-10_13.30.09.934802.jamesbond-laptop.ful
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 404, in <module>
    upgrader.upgrade_target( target, purge )
  File "/usr/sbin/upgrade_backups.py", line 60, in upgrade_target
    self.upgrade_tdir( target+"/"+adir )
  File "/usr/sbin/upgrade_backups.py", line 78, in upgrade_tdir
    v = self.openfile( tdir + "/ver" )
  File "/usr/sbin/upgrade_backups.py", line 307, in openfile
    return gnomevfs.open( uri, 1 )
gnomevfs.NotFoundError: File not found
jamesbond@jamesbond-laptop:~$

-----------

Note that this problem happens from time to time. Last time when I saw this problem, I removed all the old backup directories (As the error seems to come only when the sbackupd tries to access an old directory). For the next one week, the backup worked. Now again this problem.

I also thought that this could be because the sbackupd isn't able to delete expiring directories. So, I removed the expiry .. so that the directories are never to be deleted. That didn't help. I don't understand why sbackup wants to access those old directories anyway. Note that even if there's a newer "full" backup in place, the sbackup is still accessing the oldest directory, and throwing an error.

[Oumar Aziz OUATTARA (wattazoum)]

Hi,

please try with the file given there : https://bugs.launchpad.net/ubuntu/+source/sbackup/+bug/82992/comments/4

I believe we have fix the problem. It would be nice if you could confirm that it's fixed (or not :-) ).
so that I'll work on that one.

[Oumar Aziz OUATTARA (wattazoum)]

My bad, the bug wasn't fixed.

To reproduce, just erase the "ver" file from one snapshot. and launch simple-restore-gnome.
What has been done was to pass the error silently in upgrade_backup.py

The fix will be to erase every snapshot that doesn't contain the "ver" file . The existance of this file , in the new version, shows that a backup is complete. Otherwise the snapshot is not and should be delete.

[Oumar Aziz OUATTARA (wattazoum)]

here is the version fixed

[Paul Benkovitz (pjbgravely)]

S0 far so good. Sbackup ran last night without having to move any old backups. Of course only time will tell as it usually takes a month of backups before it stops working, but backing up to a folder full of old ones is a good sign.

[Christopher Barrington-Leigh (cpbl)]

Thanks, Ouattara!!

It's great that someone is finally able to help this poor piece of software.
But how do I know that your new version is not stealing my passwords (which, btw, for the ssh feature are stored in text format in sbackup and even EMAILED in open text to the root user (which then comes on to my normal account!!! but that's another bug) --- where is the source code? How does one get credibility in the community as a friendly, non-hacker contributor? I see you've joined recently... so that might be hard.

Well, thank you! (I ope no offense taken -- I don't suspect you in particular.)
Chris

[Christopher Barrington-Leigh (cpbl)]

Okay, that was a stupid question -- sbackup is written in Python.

However, I ran it and get the following error now: this is new to me.:

sudo sbackupd
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 426, in <module>
    upgrader.upgrade_target( target, purge )
  File "/usr/share/sbackup/upgrade_backups.py", line 59, in upgrade_target
    self.upgrade_tdir( target+"/"+adir )
  File "/usr/share/sbackup/upgrade_backups.py", line 86, in upgrade_tdir
    print "ERROR : Unexpected Exception : " + e
TypeError: cannot concatenate 'str' and 'exceptions.TypeError' objects

[Oumar Aziz OUATTARA (wattazoum)]

hello,

well, actually I have never used sbackup for backups requiring password . If it just keeps your password in clear, this might be another bug to fill up.
As for the code, since sbackup is open source you can see it there :
http://sbackup.svn.sourceforge.net/viewvc/sbackup/
(you've noticed I have joined the BugSquand recently, if you search well, you'll see that my first contribution was patches or .deb along with .tar.gz . The moment I stopped sending .tar.gz matches my entry in the sbackup team.

The error you've just shown is a combinaison of two things :
* sbackup succeds in openint the *ver* file but cannot read it ( That was very unexpected )
* But the code I put to print the error wasn't execpting Errors but just Exceptions

[Oumar Aziz OUATTARA (wattazoum)]

Here is a mod with the second point solved (so that I can have more information on the first one ) . could you please retry with this one ?

[Christopher Barrington-Leigh (cpbl)]

 sudo sbackupd
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
ERROR : Unexpected Exception : gnomevfs.Handle.read() takes exactly 1 argument (0 given)
WARNING : ssh://cpbl:<email address hidden>:/home/cpbl/private/backup/2007-04-10_10.00.19.825976.cpbl-laptop.inc/ver doesn't exist ! Deleting the incomplete snapshot
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 428, in <module>
    upgrader.upgrade_target( target, purge )
  File "/usr/share/sbackup/upgrade_backups.py", line 59, in upgrade_target
    self.upgrade_tdir( target+"/"+adir )
  File "/usr/share/sbackup/upgrade_backups.py", line 81, in upgrade_tdir
    self.delete( tdir )
  File "/usr/share/sbackup/upgrade_backups.py", line 280, in delete
    d.close()
AttributeError: 'gnomevfs.DirectoryHandle' object has no attribute 'close'

[Oumar Aziz OUATTARA (wattazoum)]

Nice :-D

That is what I was thinking . All my tests were made locally , so I
didn't use the right function for remote backups . I'll work on that
one .

Thank you

Question : is this backup a good one ? Do you want to keep it ?
2007-04-10_10.00.19.825976.cpbl-laptop.inc

cause, since there is no "ver" file inside, it would be deleted as an
incomplete one .

[Oumar Aziz OUATTARA (wattazoum)]

Fixed version ( tested over ssh :-) )

Format: 1.7
Date: Thu, 10 May 2007 22:01:42 +0200
Source: sbackup
Binary: sbackup
Architecture: source all
Version: 0.10.4beta8
Distribution: feisty
Urgency: low
Maintainer: Aigars Mahinovs <email address hidden>
Changed-By: Ouattara Oumar Aziz (alias wattazoum) <email address hidden>
Description:
 sbackup - Simple Backup Suite for desktop use
Changes:
 sbackup (0.10.4beta8) feisty; urgency=low
 .
   * Resolved a bug when using ssh

[Christopher Barrington-Leigh (cpbl)]

If I already sent this privately, it didn't make it to the launchpad. This version still doesn't work for me over remote backup site:

..remote site:/._10.00.27.151010.cpbl-laptop.ful/ver doesn't exist ! Deleting the incomplete snapshot
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 428, in <module>
    upgrader.upgrade_target( target, purge )
  File "/usr/share/sbackup/upgrade_backups.py", line 59, in upgrade_target
    self.upgrade_tdir( target+"/"+adir )
  File "/usr/share/sbackup/upgrade_backups.py", line 81, in upgrade_tdir
    self.delete( tdir )
  File "/usr/share/sbackup/upgrade_backups.py", line 280, in delete
    d.close()
AttributeError: 'gnomevfs.DirectoryHandle' object has no attribute 'close'

Thanks!

[Oumar Aziz OUATTARA (wattazoum)]

Fixed.

Thank you for your help in bug report. :-)

[Christopher Barrington-Leigh (cpbl)]

WARNING : ssh://cpb:@gcra-ubc.com:/home/cpbl/private/backup/2007-04-12_10.00.27.151010.cpbl-laptop.ful/ver doesn't exist ! Deleting the incomplete snapshot
I: Upgrading to v1.4: ssh://cpb:@gcra-ubc.com:/home/cpbl/private/backup/2007-04-11_10.00.29.252716.cpbl-laptop.inc
WARNING : ssh://cpbl:@gcra-ubc.com:/home/cpbl/private/backup/2007-04-10_10.00.19.825976.cpbl-laptop.inc/ver doesn't exist ! Deleting the incomplete snapshot
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 428, in <module>
    upgrader.upgrade_target( target, purge )
  File "/usr/share/sbackup/upgrade_backups.py", line 62, in upgrade_target
    self.purge( target, listing, purge )
  File "/usr/share/sbackup/upgrade_backups.py", line 254, in purge
    self.delete( target+"/"+adir )
  File "/usr/share/sbackup/upgrade_backups.py", line 269, in delete
    if not self.isdir( uri ):
  File "/usr/share/sbackup/upgrade_backups.py", line 283, in isdir
    return ( gnomevfs.get_file_info( uri ).type == 2 )
gnomevfs.NotFoundError: File not found

[Christopher Barrington-Leigh (cpbl)]

This may be a separate bug, but it's worse... [again, I wonder, am I the only one trying to use this as my remote backup solution?!]:

when I run sbackup from the command line, it SILENTLY fails to finish the backup. That is, an incomplete .tgz file is written.
After only a couple of minutes, it stops writing. There is no error and sbackupd does not terminate. And the lock file is still there.

(Btw, trying your recent version, despite giving an error it did delete what it needed to so that when I ran sbackupd a second time, it went ahead without error. But with this new, bigger problem).

So I end up with a "full" backup that is about 30 MB in stead of 1.1 GB.

Okay, this new problem happens with the latest v1.3 too. But it didn't used to.
...

[Christopher Barrington-Leigh (cpbl)]

The post above seems to describe a problem that happened repeatably over a wireless connection but not so far wired. I don't know why, but maybe the connection was intermittent and sbackup does not catch breaks in the connection.
So I don't claim this is a problem that has been introduced in fixing the current bug.

There is still one remaining problem I've seen (two posts ago) with your fix.

When that is wrapped up and a fixed version appears on Feisty's servers as a bug-fix push, I'd like to send you (Ouattara) a token payment for your help with this (if that doesn't contradict any launchpad policies).

Thanks!
c

[Oumar Aziz OUATTARA (wattazoum)]

> The post above seems to describe a problem that happened repeatably over a wireless connection but not so far wired. I don't know why, but maybe the connection was intermittent and sbackup does not catch breaks in the connection.
> So I don't claim this is a problem that has been introduced in fixing the current bug.

So this might be a problem of sbackup not handling connection breakage .
 I though it was a problem with gnomevfs too, but I can understand that
there is a problem if the connection breaks . Maybe you must fill it as
another bug ...

>
> There is still one remaining problem I've seen (two posts ago) with your
> fix.

I think I have fixed it (if the problem you're talking about is the
"gnomevfs.NotFoundError: File not found" one ). we have also changed the
behaviour so that incomplete snapshots are not removed automatically .

>
> When that is wrapped up and a fixed version appears on Feisty's servers
> as a bug-fix push, I'd like to send you (Ouattara) a token payment for
> your help with this (if that doesn't contradict any launchpad policies).
>
> Thanks!
> c
>
Ohh :-) that's so generous of you. What I like the most is to see people
happy when I try to solve bugs . That's my main payment :-)
FYI , I don't think launchpad has any problem with that. (
https://launchpad.net/legal )

[Oumar Aziz OUATTARA (wattazoum)]

Hi,

Can I set this one as fix committed ?

[mbneimann (mikael-neimann)]

Hi

I'm trying to make an incremental backup of /home to a remote ftp site and I experienced the same errors as described above.

I've just tested 0.10.4-beta10 and get the following error:

mbneimann@capone:~$ sudo simple-backup-config
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 428, in <module>
    upgrader.upgrade_target( target, purge )
  File "/usr/share/sbackup/upgrade_backups.py", line 59, in upgrade_target
    self.upgrade_tdir( target+"/"+adir )
  File "/usr/share/sbackup/upgrade_backups.py", line 78, in upgrade_tdir
    if int(ver[0]) < 2 and int(ver[2:]) < 3:
IndexError: string index out of range

Hope you can make something of this.

Best regards
Mikael B. Neimann

[Oumar Aziz OUATTARA (wattazoum)]

should be fixed.

Could you please test this ?
It should still print the error for Info.

[mbneimann (mikael-neimann)]

Hi

Backup works! :-)

Just before running the beta11 version I noticed that the ver file on the server was empty. I did some cleaning up (deleted old backups) and now it works. I've tried both full and incremental backup.

Thank you very much!

Not sure about restore tho'...! I get the following result no matter what I chose to restore.

sudo simple-restore-gnome
E: File not found in the backup snapshot
E: File not found in the backup snapshot
E: File not found in the backup snapshot
E: File not found in the backup snapshot
E: File not found in the backup snapshot

Best regards
Mikael B. Neimann

[Oumar Aziz OUATTARA (wattazoum)]

OOhh, That's scary !
You're right :-/

The good thing is the problem comes from Restore (but the backup is valid )

As for the cleaning up you have done , the beta 11 new code would have, somehow, done it . Itwouldn't have deleted the whole snapshot dir but the ver file so that next time it wouldn't look inside.

[Oumar Aziz OUATTARA (wattazoum)]

Fixed .

Could you please test it ?

[mbneimann (mikael-neimann)]

Restore works now!

A couple of things could make it a bit more pretty.

1) When I restored an empty dialog box appeared

2) When I chose to restore to an alternative destination ("Restore As...") the console output showed the original path. Thought for a moment I had overwritten some files.
Example:
I did a backup of /original-folder and chose to restore it to /new-folder. The console output was:
...
/original-folder/somefile1
/original-folder/somefile2
/original-folder/somefile3
/original-folder/somefile4
...

3) The simple-restore-gnome dialog starts up real slow, due to contacting the remote backup site before showing the dialog.

:-) Mikael

[Oumar Aziz OUATTARA (wattazoum)]

HI,

Please fill another bug in for those .
You can add in it that Simple-restore-gnome is very slow when restoring too .
Idea for the bug title : Request for simple-restore-gnome improvement .

Thank you

[Jesús García Sáez (blaxter)]

Hi, just wanna say, with the last .deb, sbackup_0.10.4~beta12_all.deb, it works perfectly for me. Using ssh (with pass) remote backups. Thanks a lot! :)

[Oumar Aziz OUATTARA (wattazoum)]

Changing status to Fix committed as it's fixed upstream.

Please feel free to reopen if there is any problem concerning that bug.

[jodsalz (jodsalz)]

I use version sbackup_0.10.4~beta12_all.deb on feisty, but it doesn't work at all:

first try:

jod@jod-desktop:~$ sudo sbackupd
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 593, in <module>
    do_backup_finish()
  File "/usr/sbin/sbackupd", line 280, in do_backup_finish
    tardst = gnomevfs.create( turi, 2 )
gnomevfs.LoginFailedError: Login failed

second try:

jod@jod-desktop:~$ sudo sbackupd
W: Error reading ftp://jod:<email address hidden>/backup/2007-06-28_15.05.58.524179.jod-desktop.ful/ver ! Ignoring incomplete or non-backup directory.
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 593, in <module>
    do_backup_finish()
  File "/usr/sbin/sbackupd", line 280, in do_backup_finish
    tardst = gnomevfs.create( turi, 2 )
gnomevfs.LoginFailedError: Login failed

On "server.com/backup/2007-06-28_15.05.58.524179.jod-desktop.ful/" I have two files: excludes and packages. But I don't see a backup-file of /home/jod - which I expected...

I don't have the slightest idea what this means, but maybe it helps you to fix the program...
thanks!

[Oumar Aziz OUATTARA (wattazoum)]

HI,

apparently, gnomevfs couldn't login to your web site , I suspect that the ftp is configured to just get 1 connection at a time and that gnomevfs is trying to open another one.

do you know if there is a user connections limitation on your ftp ?

[jodsalz (jodsalz)]

i tried to connect via browser and gftp and nautilus... and this is what i got:

530 Sorry, the maximum number of clients (2) from your host are already connected.

so - this is the problem? i started sbackup again and got following error:

jod@jod-desktop:~$ sudo sbackupd
E: Target directory is not writable - please test in simple-config-gnome!

(--> note that it must be: simple-backup-config - not simple-config-gnome!)

there i tested the connection and got the error:

"the selected destination is not writtable with current permissions. the backups can not be written there."

in case of connections limitation it seems to produce another error-output. when i tested the connection at my first try i got an "ok"...

[Oumar Aziz OUATTARA (wattazoum)]

Hi,

I guess sbackup error report is confusing and I am aware of that. I think your problem is really about connection limitation. but actually Sbackud (in simple-backup-config ) report and error about writability for any problem that occurs and prevent it to write (or even access the target ).

Basically, connection limitation is a big problem with software in the open source world . That is due to non optimized development . Usually, 2 connections should be enough for everything . But some times connections are opened while existing ones should be used .

What I suggest is that you open a new bug report on sbackup with your first comment, so that we don't lose this bug .

Thank you