I am certain you won't be surprised, using the correct value in the --time OPTION fixed my problem. I was indeed able to restore a file prior to an empty set incremental, but better than that, I've incorporated the test command in crontab so that I no longer create empty backups.
Thank you very much. I don't often get such directly applicable help from mailing lists.
> On Tue, Aug 22, 2023, at 12:31, Nate Eldredge wrote:
>> On Mon, 21 Aug 2023, duplicity--- via Duplicity-talk wrote:
>> Are you certain that you specified a timestamp between #1 and #3?
>> Sometimes time zones can lead to mistakes.
>> Can you reproduce this with a smaller test case, showing the exact
>> commands you ran to do the backups and restores?
> I am confident I used the correct time and timezone of the timestamp on
> the file I edited so that it would be backed up in the incremental. I'm
> also now thinking maybe I should set --time to some seconds before the
> file timestamp as I don't know how time is calculated.
Hmm, then I would be interested in seeing a test case if you can reproduce
it.
Note that what counts is not the time stamp on the file, but the times at
which the backups were made. This time is included in the filenames of
the backup archives (duplicity-full.xxx.manifest.gpg, .difftar.gpg, etc).
E.g. if your #1 backup (with the file present) happened on June 1, and #3
(with the file not present) happened on June 10, then you should specify a
--time something like June 5. Regardless of the timestamp on the file
itself. The Unix timestamps on the backup archive files are also
irrelevant.
>> 0 0 * * * [ -e /mnt/foo/myfile ] && duplicity ...
> I follow that if [ -e /mnt/foo/myfile ] works, the duplicity script will run. I have to understand what [ -e /mnt/foo/myfile ] does but will work on it.
See `man test` for the syntax. `[ -e file ]` succeeds (exit status 0) if
file exists, otherwise fails (exit status nonzero). So the job runs
duplicity if and only if /mnt/foo/myfile exists.
--
Nate Eldredge