--file-changed does not work

[Dan B]

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

[shaochun (shaochun)]

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.

[shaochun (shaochun)]

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:
............................

[Sjoerd de Haan (sjdh)]

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:
-------------------------

[Kenneth Loafman (kenneth-loafman)]

Option removed completely.

[c sights (cwseys)]

:(

[Anthony (0othan)]

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

[Kenneth Loafman (kenneth-loafman)]

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
>

[Anthony (0othan)]

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