I shortened the filename because I was trying to confirm another fix so I do not have a log, but the error about unsupported characters seems common on the forum.
There are some threads recommending base64 file encoding to resolve this but I did find one that explored using base32768 with IDrive. This lead to a bug report though it seems the issue was down to each of the specific different characters the test uses requiring extra escape characters.
It the issue is with base32768 and IDrive is just down to the specific characters and their escapes used in the test, does this mean I should opt for this over base64?
I am still setting up so my remote is only 10 GiB, can you please tell me if the steps below will resolve this:
move the local directory to a backup
backup rclone.conf
rclone config delete idrive-sync-crypt
on the IDrive web UI remove all files in the bucket
recreate the crypt using the config wizard
manually add a line for filename_encoding = base64
create RCLONE_TEST and run a basic test of rclone sync
run the bisync command for the first time only with --re-sync
Also, is storage generally moving away from base32, so that at some point in the future that is not likely to cause an issue migrating? Very happy with IDrive but thought it may be worth considering.
I found several more recent threads since recommending base64 for IDrive. Re-created the crypt selecting base64 from the advanced configuration options of the wizard and this seems to work just fine.
All base32, base64 and base32768 are supported when using iDrive.
Max length of any file name here is 1024 characters (assuming 1 byte encoding)
base32 is 5 bits encoding so it allowa to encode 1024*5/8 = 640 bytes base64 is 6 bits - 1024*6/8 = 768 bytes base32768 is 15 bits but in case of iDrive every character counts as 2 bytes, so 512*15/8 = 960 bytes
I would use base32768 but base64 is not much worse.
There is no general trend here. Encoding you can use depends on your storage characteristic. Is it case sensitive or not? Does it support all Unicode characters needed by base32768?
base32 is least efficient but most portable - it works everywhere base64 requires case sensitive storage (Google Drive, S3 etc.) base32768 requires specific Unicode support
If base32768 works it makes sense to switch to that, though I would not like to regret this in the future, which is why I was asking if there was a trend. Is this something that concerns you?
As great as IDrive are, and unlikely as it may be, if in the future I was forced to move my data to another provider, I assume there are ways to migrate directly between providers, once they support the same encoding, without having to fully sync from a local system.
If in the event they do not, and instead my options are limited to base64 or base32, would the option I have seen mentioned move --server-side-across-configs negate this being an issue, so that the only problem would be renaming files that error due to their length?
If you want to be able to move directly between any provider then your only option is base32 - full stop.
But I am not sure why you pay such attention to it. Moving directly or re-encoding everything is the same network bandwidth required. And unless you run it on raspberry pi zero any modern hardware has enough ouph to handle it without sweat.
BTW with rclone test you can also check whether remote can use base32768:
$ rclone test info --check-base32768 iDrive:test
2024/06/15 14:38:13 NOTICE: S3 bucket test path rclone-test-info-puqovil2/test-base32768: 0 differences found
2024/06/15 14:38:13 NOTICE: S3 bucket test path rclone-test-info-puqovil2/test-base32768: 1028 matching files
// iDrive
base32768isOK = true // make sure maxFileLength for 2 byte unicode chars is the same as for 1 byte characters