--file-changed does not work

Bug #1526557 reported by Dan B
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Duplicity
Fix Released
Medium
Unassigned

Bug Description

Duplicity 0.7.06
Ubuntu 14.04
Python 2.7.6

The --file-changed option with collection-status does not work. Restoring files work just fine.

Several months of daily backups are available when testing this.

$ duplicity collection-status --file-changed home/user/filename --gio sftp://user@server/home/user/backups
Warning: Option --gio is pending deprecation and will be removed in a future release.
Use of default filenames is strongly suggested.
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Mon Oct 5 09:38:37 2015
-------------------------
File: home/user/filename
Total number of backup: 0
 Type of backup set: Time: Type of file change:
-------------------------

$ duplicity restore --file-to-restore home/user/filename --gio sftp://user@server/home/user/backups restored_file
Warning: Option --gio is pending deprecation and will be removed in a future release.
Use of default filenames is strongly suggested.
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Mon Oct 5 09:38:37 2015

This should be easily reproduced. I noted someone else having the same problem: https://lists.gnu.org/archive/html/duplicity-talk/2015-11/msg00008.html

Revision history for this message
shaochun (shaochun) wrote :

I am using 0.7.06+bzr1166-0ubuntu0~ubuntu14.04.1 from the https://launchpad.net/~duplicity-team/+archive/ubuntu/daily (2015-12-24) along with Python 2.7.6 and Ubuntu 14.04.3 LTS and the --file-changed option with collection-status does not work either.

Revision history for this message
shaochun (shaochun) wrote :

after some experiment:
relative-paths work fine, but absolute-ones don't:

--------------------------------------------------------------------------
$ ls -R backup
backup/scene:
duplicity-full.20160101T045912Z.manifest.gpg
duplicity-inc.20160101T045912Z.to.20160101T050021Z.manifest.gpg
duplicity-full.20160101T045912Z.vol1.difftar.gpg
duplicity-inc.20160101T045912Z.to.20160101T050021Z.vol1.difftar.gpg
duplicity-full-signatures.20160101T045912Z.sigtar.gpg
duplicity-new-signatures.20160101T045912Z.to.20160101T050021Z.sigtar.gpg

$ ls -R data
data/scene:
1 2 3

--------------------------------------------------------------------------
$ duplicity collection-status --file-changed 1 file://./backup/scene

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Jan 1 04:59:12 2016
............................
File: 1
Total number of backup: 2
 Type of backup set: Time: Type of file change:
                Full Fri Jan 1 04:59:12 2016 New
         Incremental Fri Jan 1 05:00:21 2016 Changed
............................

--------------------------------------------------------------------------
$ duplicity collection-status --file-changed 1 file:///full/path/to/backup/scene

............................
File: 1
Total number of backup: 0
 Type of backup set: Time: Type of file change:
............................

Changed in duplicity:
assignee: nobody → Kenneth Loafman (kenneth-loafman)
importance: Undecided → Medium
milestone: none → 0.7.07
status: New → In Progress
Changed in duplicity:
milestone: 0.7.07 → 0.7.08
Changed in duplicity:
milestone: 0.7.08 → 0.8.00
Revision history for this message
Sjoerd de Haan (sjdh) wrote :

On my setup, the collection status does not work either. Also the suggestion of shaochun to use relative URL's does not work.

Linux 4.14.4-1-ARCH #1 SMP PREEMPT Tue Dec 5 19:10:06 UTC 2017 x86_64 GNU/Linux
Python 2.7.14
duplicity 0.7.15

This is what I am doing

$ duplicity list-current-files file://./test_backup/no_encryption
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sun Dec 10 08:44:38 2017
Sun Dec 10 08:44:37 2017 .
Sun Dec 10 08:44:37 2017 file1
Sun Dec 10 08:44:39 2017 file2

$ duplicity collection-status --file-changed "file2" file://./test_backup/no_encryption

Last full backup date: Sun Dec 10 08:44:38 2017
-------------------------
File: file2
Total number of backup: 0
 Type of backup set: Time: Type of file change:
-------------------------

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

Option removed completely.

Changed in duplicity:
milestone: 0.8.00 → none
assignee: Kenneth Loafman (kenneth-loafman) → nobody
status: In Progress → Invalid
Revision history for this message
c sights (cwseys) wrote :

:(

Revision history for this message
Anthony (0othan) wrote :

So this option will not be added in 0.8? :X

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote : Re: [Bug 1526557] Re: --file-changed does not work

Not as it was implemented. Way too much memory use!

On Tue, Jan 28, 2020 at 12:35 PM Anthony <email address hidden> wrote:

> *** This bug is a duplicate of bug 1044715 ***
> https://bugs.launchpad.net/bugs/1044715
>
> So this option will not be added in 0.8? :X
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/1526557
>
> Title:
> --file-changed does not work
>
> Status in Duplicity:
> Invalid
>
> Bug description:
> Duplicity 0.7.06
> Ubuntu 14.04
> Python 2.7.6
>
> The --file-changed option with collection-status does not work.
> Restoring files work just fine.
>
> Several months of daily backups are available when testing this.
>
> $ duplicity collection-status --file-changed home/user/filename --gio
> sftp://user@server/home/user/backups
> Warning: Option --gio is pending deprecation and will be removed in a
> future release.
> Use of default filenames is strongly suggested.
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: Mon Oct 5 09:38:37 2015
> -------------------------
> File: home/user/filename
> Total number of backup: 0
> Type of backup set: Time: Type of file
> change:
> -------------------------
>
> $ duplicity restore --file-to-restore home/user/filename --gio
> sftp://user@server/home/user/backups restored_file
> Warning: Option --gio is pending deprecation and will be removed in a
> future release.
> Use of default filenames is strongly suggested.
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: Mon Oct 5 09:38:37 2015
>
> This should be easily reproduced. I noted someone else having the same
> problem: https://lists.gnu.org/archive/html/duplicity-
> talk/2015-11/msg00008.html
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/1526557/+subscriptions
>

Revision history for this message
Anthony (0othan) wrote :

Hi @Kenneth,

What do you mean? Will be implemented with another way or will not be implemented in 0.8?

If will be implemented in another way, do you have planned date? (this year by example? In the next months?

Because this feature is very usefull & I think that during the time to find a new way to implement it, it's not a big issue to use the old one like workaround (with maybe a warning in the man page to prevent that can use too much memory).

Thank you very much

Changed in duplicity:
status: Invalid → Fix Committed
milestone: none → 0.8.12
Changed in duplicity:
status: Fix Committed → In Progress
assignee: nobody → Kenneth Loafman (kenneth-loafman)
Changed in duplicity:
status: In Progress → Won't Fix
status: Won't Fix → Fix Released
assignee: Kenneth Loafman (kenneth-loafman) → nobody
Changed in duplicity:
status: Fix Released → Fix Committed
Changed in duplicity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers