File and directory differenging only in case: how to manage it?

[Rmano (Romano Giannetti)]

I am using rclone to backup my Linux directory on my employer's OneDrive cloud disk --- and it works perfectly and efficiently. Kudos to everyone involved.

The problem is that I have, on my source disk, a project cloned by GitHub; can't post a link, search for screenkey. In that dir there is a file named screenkey and a directory named ScreenKey. Ok: bad idea, I know.

What happens is that clearly, the copy fails because the target fs is non-case-sensitive with the error reported below.

So, my question: is there some way of solving the clash short of excluding the guilty directory from the backup?

• Forum notice: I was not able to add the data requested because the interface tells me that I have too much links, when there are no links in the post. So I am posting this and adding the data too see where it fails... (ok, it seems that the forum filter counts #### markers as links)

version: rclone v1.53.3

OS: Ubuntu Linux 20.04, 64 bits

target: Onedrive

command:

rclone sync --exclude-from="$HOME/rclonedir/filtering.txt"\
        --fast-list --skip-links\
        -P --log-file=software-rclone.log --log-level=INFO\
        "$HOME/software"  target:Backups/Live/software/

The rclone config contents with secrets removed:

[target]
type = onedrive
token = {"access_token":}
drive_id = b!LtHke
drive_type = business

log file:

Clearly, the error is for every file in the "misnamed" directory.

2021/04/11 21:02:14 ERROR : gnome-utils/screenkey/Screenkey/__init__.py: Failed to copy: found file when looking for folder
.... (much more)

[ncw (Nick Craig-Wood)]

@Rmano

So, my question: is there some way of solving the clash short of excluding the guilty directory from the backup?

You could use the crypt backend with filename encryption - that should work, though that does seem like a sledgehammer to crack a nut.

I can't think of another workaround other than excluding the directory.

[Rmano (Romano Giannetti)]

Thanks. Yes, excluding the directory is what I ended up doing (the error would stop the delete phase, which is a problem).
I hoped in a kind of mangling names in this case, or a possible a "just ignore it" flag (as it happens when the case-clash is just in two different files). But I understand that this is really an error, because the data is not saved, and so it must be shown prominently.