Closed johnsturgeon closed 2 months ago
@toddejohnson can you help ponder this? The testing looked good in #165, so now I'm not sure what is different now.
I am going to write up a patch that uses -exec rm -rf {} \;
...that solution sounds good in any case
OK, circling back.. I don't know what's wrong actually. I can say with certainty that last night's backup did not prune my old directories, but it does look like rsync
s prune does it correctly (my bad for mis-reading it from the original diagnosis) -- Maybe it needs to be -rf
??.
I'll let this run a few days and see if the issue reproduces itself, and maybe I'll add a bit more logging. In the mean time I'll hold off on a patch.
Sure thing!
The https://github.com/itzg/docker-mc-backup/blob/f3031a8c212af026cc604eb75751809a036727f4/scripts/opt/backup-loop.sh#L318 should be taking care of that with rm -r
. The find is called from purge.
Debugging more tonight
@johnsturgeon Awesome find with the -a
time issue! I was about to dig into that too.
This was changed in #169
And #177 is now merged and built
This was changed in #169
Indeed! Thanks @toddejohnson . I must have had an older image, and when I was doing testing, pulled a new image and got your change.. I confused the daylights out of me since I DEFINITELY had the same issue ...
Nice to know I'm not going crazy
Found another issue with
rsync
method.When pruning old directories, it does not work since the directories have 'files'.
The current prune command is this:
find ${DEST_DIR} -type d -maxdepth 1 -mtime +1 -print -delete
The problem with
rsync
is that these are not just 'files' but rather directories, the-delete
flag only works with files (it seems)Here's the output from the docker console:
I am going to write up a patch that uses
-exec rm -rf {} \;