CobianSoft

Great work on Cobian Reflector!

Wondering if you're aware about it failing to process directories
that contain trailing spaces in directorynames.

Yes, renaming those is a manual workaround (and a challenge in itself ).
It seems though as these originate from Mac clients accessing via SMB shares
that seem to like doing trailing spaces. So new ones might pop up.

There are there errors in this context
1. error counting files in the directory.
2. error counting files is not reported as "ERR "
3. error backing up the directory

It is reproducible.
Creation of sample dir/files to test is easiest done with wsl

Here a sample Backup log file (Cobian Reflector 0.9.78 on Windows10):

2022-01-23 18:59:01 A backup has started...
2022-01-23 18:59:01 Calculating the number of files. This could take a while...
2022-01-23 18:59:01 An error occurred while counting files. Error reported on file "C:\TESTDIR\dirwithtrailingspace ": C:\TESTDIR\dirwithtrailingspace

2022-01-23 18:59:01 Backing up the task "TRAILSPACETESTBACKUP"
2022-01-23 18:59:01 Applying the parameters to the task "TRAILSPACETESTBACKUP" (if any).
2022-01-23 18:59:01 Starting the copy. The user running the task is: loske
2022-01-23 18:59:01 The destination directory "C:\TESTBACKUPDEST\TESTDIR-20220123_185901 (Full)" has been successfully created.
2022-01-23 18:59:01 Backing up the directory "C:\TESTDIR" to "C:\TESTBACKUPDEST\TESTDIR-20220123_185901 (Full)"...
ERR 2022-01-23 18:59:01 An error occurred while listing the content of the directory "C:\TESTDIR\dirwithtrailingspace ": C:\TESTDIR\dirwithtrailingspace
2022-01-23 18:59:01 The archive attribute for "C:\TESTDIR" has been removed.
2022-01-23 18:59:01 The file attributes have been copied from "C:\TESTDIR" to "C:\TESTBACKUPDEST\TESTDIR-20220123_185901 (Full)".
2022-01-23 18:59:01 The timestamps have been copied from "C:\TESTDIR" to "C:\TESTBACKUPDEST\TESTDIR-20220123_185901 (Full)".
2022-01-23 18:59:01 The directory "C:\TESTDIR" has been backed up.

2022-01-23 18:59:01 * Backup part for the task "TRAILSPACETESTBACKUP" has ended *
2022-01-23 18:59:01 * Number of backed up files: 1. Backup part size: 7 bytes. *
2022-01-23 18:59:01 A sub-backup item has been added to the database.
2022-01-23 18:59:01 A backup item has been added to the database.
2022-01-23 18:59:01 Deleting some full backups and associated differential/incremental backups. Reason: maintaining only 3 non-parked full backup sets.
2022-01-23 18:59:01 The sub-backups have been deleted. Actual files may be being deleted on a background thread.
2022-01-23 18:59:01 The backups have been deleted. Actual files may be being deleted on a background thread.

2022-01-23 18:59:01 ** Backup for the task "TRAILSPACETESTBACKUP" has ended **
2022-01-23 18:59:01 ** Processed files: 1. Backed up files: 1. Created folders: 1. Backup size: 7 bytes. **
2022-01-23 18:59:01 ** Number of errors: 1. Time elapsed: 0 hours, 0 minutes, 0 seconds. **

2022-01-23 18:59:02 The backup has ended. There are errors. Consult the log file.

2022-01-23 18:59:02 Getting the backup history for the task "ce395ebb-4e84-473d-b59d-2814736bf4f2"...

Thanks!

I will take a look at that.

Have investigated this and it seems like this is a Windows problem...

From MSDN "Naming Files, Paths, and Namespaces (Windows)":

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not.

Problems can arise when a Macintosh client creates a file on a Windows NT server. The code to remove trailing spaces and periods is not carried out and the Macintosh user gets the correctly punctuated filename. The Win32 APIs FindFirstFile() and FindNextFile() return a filename that ends in a space or in a period; however, there is no way to create or open the file using the Win32 API.

So this will be causing a lot of errors. For example, I think you will have a lot of problems deleting or renaming those directories.

Thank you for checking this.

Yes, it is kind of tricky to deal with these directories.
Especially as they do not have a 8.3 shortname that could be leveraged to at least move files and then delete these directories.

Interestingly using a current Apple device did not allow to rename the directories either.
Seems that Apple fixed that loophole in the meantime.

Just in case anyone else encounteres the same, what finally helped to get rid of the "infected" directories:
mount the SMB share on a linux box (opensuse in wsl , cifs-utils installed).
Options are needed to be able to rename and also process directories with non ascii characters.

mount -t cifs -o vers=1.0,iocharset=utf8,username=<username> //server/share /mnt/mntname

then rename via normal mv "directoryname " "directoryname"

Thanks