Prune operation creates spurious (empty) log file

When I run the command “duplicacy prune -log -keep … -all” it creates a file named “prune-log-yymmdd-hhmmss” in the repository’s .duplicacy/logs directory, as well as producing the expected log information on stdout. Comparing this behaviour with (for example) the behaviour of the backup command, it seems to me that this log file should not be created.

So far I have only seen this spurious log file have zero size, but that may be because the corresponding prune operations have not yet deleted any snapshots.

I wonder whether this is a bug or something more subtle that I don’t understand…

(This is with duplicacy 2.1.1 on macOS 10.12.)

There is an enhancement proposal for the issue: Prune should write in the log when there's nothing to be pruned · Issue #424 · gilbertchen/duplicacy · GitHub

Hmm - my concern was more that prune should not create a log file but rather send all its output to stdout.

Following the link you posted, I came to Weird logging behaviour · Issue #8 · TheBestPessimist/duplicacy-utils · GitHub which also mentions this behaviour, but it doesn’t seem to have been addressed.

It’s good that prune also creates a log file because when something is pruned it can be checked at a later time.
There are very few people who are using other scrips along with duplicacy, and i’d assume most people are using GUI and not CLI. In these cases that prune file is really useful.

I understand you’re saying that creating the log file is by design - fair enough, thanks. Perhaps that difference in behaviour (from the other operations) should be documented, then.

You’re suggesting just to note in Prune command details that prune writes a log file and that it may also be empty if nothing was modified, or something more?

Exactly that, thanks. At least if I’d read that I wouldn’t have tried to track down where that unexpected file was coming from, and wouldn’t have raised a bug report :slight_smile:

1 Like