Empty folders after prune

Support
#1

Hi,

I’m trying to delete a repository. Running the following command deletes the snapshot (assume that only one revision exists):

duplicacy prune -r 1 -exclusive

I checked my google drive and the snapshot and chunks are indeed removed. However, quite a few empty folders remain in the /chunks and in /snapshots. /snapshots has my repo folder but it’s empty. I also find empty folders in /.duplicacy/cache. Is there a CLI command to remove all these empty folders?

Also, why do I have to specify -r 1 in the prune command? When I just use duplicacy prune -all -exclusive, it tells me that there are no snapshot to delete when I have revision 1? Do snapshot and revision refer to different things?

First backup/prune and chunks left/skipped
#2

Any users facing this as well? Or is this intended behavior? that empty folders in /chunks remain after pruning

#3

I’d definitely not tinker with the /chunks directory if I were you - if you still have any backup data in the storage, that is.

As far as I know, Duplicacy now only maintains a single level folder structure in there, so you’ll only ever see 256 directories - 00 through FF. Future backups will only recreate these folders and if you have even a small quantity backed up, all 256 directories should exist eventually. It would be very unlikely not to, since the hashing algorithms usually produce equally distributed chunk IDs.

It’s safe to manually delete an empty /snapshot/<repository> directory if indeed it is no longer needed.

I believe specifying the last revision (in your case -r 1) along with -exclusive is necessary to bypass a safety measure that prevents the most recent snapshot from being accidentally pruned.

5 Likes
#4

Hi, thanks for the reply! It was super helpful. I’m in the process of selecting a backup software and am just testing different commands in duplicacy to see if it fits my use. Do you know if empty snapshot folders is also intended behavior? For example, an empty repo folder remains in /snapshots on my google drive even after pruning all revisions of that repo.

Also, when setting up a second repo, I find that the local /.duplicacy/snapshots folder contains a folder for the first repo:

repo2/.duplicacy/snapshots/repo1
repo2/.duplicacy/snapshots/repo2

Is this also normal?

Thanks again!

#5

While I wouldn’t say it’s intended behaviour, it is normal that Duplicacy would leave behind an empty /snapshot/<repo> folder on the storage if you intentionally prune it…

At the same time, it’s not common to want to delete repositories, and having a left over snapshot directory on the storage isn’t harmful in any way. As I say, you can always manually delete it once you’re sure it’s not longer needed.

As for the local .duplicacy directory, I assume you mean the contents of the cache subfolder?

And yes, if you run prune operations from that repository (though it’s recommended to do it from one repository), Duplicacy needs to download a small amount of cache for the metadata of all repositories in order to determine what chunks should be kept vs removed.

The .cache folder can be deleted at any time (when Duplicacy isn’t running of course) and it’ll be recreated where necessary. However, it only needs to cache a small amount of what is absolutely necessary and it will regularly disguard unused data.

1 Like