Hi there, On Sat, 21 Feb 2026, Elio Coutinho wrote:
I've reported on github an issue on BackupPC_backupDelete, in which it is unable to delete a folder inside a share. GWHAYWOOD said there's a new version of DirOps.pm that would help. I'd be happy to test it, if you would mind to share it.
It seems that there might be more than one issue in BackupPC issue
#557 on Github.
Firstly the BackupPC Web interface will show files and directories
which are not actually present in the pool directories (incremental
backups) because they have not changed from a previous backup. This
is for convenience and efficiency but it may lead to couterintuitive
behaviour. BackupPC_backupDelete won't delete something which isn't
actually there.
Secondly the code both in BackupPC_backupDelete and the modules which
support it could probably benefit from more testing in non-Unix/Linux
systems. Use of the forward slash character "/" in file and directory
names might well cause problems. At present much of the code assumes
that this is always the path separator character, and that otherwise
it will not appear. I am not sure if that is the case in the report
in issue #557. More information would be helpful.
The version of DirOps.pm which is attached is much more verbose if you
set $conf{XferLogLevel} to 4 or 5. Please treat this as experimental.
At LogLevel 4 it will log a message if you try to delete something
from a backup which is not actually present in that particular backup.
At LogLevel 5 it will in addition log what it is asked to delete and
confirm what it has deleted. It will show how it walks the directory
tree. It will log some failures which are *expected*, when it tries
to 'unlink' a directory without first checking that it is a directory.
This is an efficiency measure to avoid unnecessary stat() calls and is
not an indication that something is wrong.
As well as being used by BackupPC_backupDelete, the code in DirOps.pm
is used in routine operation by BackupPC whenever an old backup needs
to be removed. Consider the logging carefully. Backups may take much
longer if verbose logging is enabled, especially if a full backup is
deleted - because verbose logging may write more than one line to the
log for each deleted file. Not only may this mean that some backups,
that would have been expected to complete if verbose logging was not
enabled, do not in fact complete e.g. overnight, but also it may mean
that log files are very large so storage space comes under pressure.
I am running this version of DirOps.pm on a server here. It seems to
work OK, but it's early days for something with so many changes.
--
73,
Ged.
DirOps.pm.gz
Description: DirOps.pm.gz
_______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/
