Hi,
I know this topic has been discussed several times, but I believe it hasn't been addressed yet, so I may try to bring my (humble) contribution if you think this is relevant.
As stated in the title, it's about creating a new virtual backend, let's call it "truncater" (or "shortener", any suggestion is welcome).
This would allow to bypass the filename length restrictions with various backends, including chunker and crypt (as described in the docs).
As I see it, if dirnames or filenames exceed the given limit, the truncater backend would simply create a .rclone.short file in current directory, that would list the alias to the real names.
So that:
./
└── A very long directory name that exceeds the limit
├── And another long long filename that must be truncated.mkv
├── And another long long filename that must be truncated.srt
├── A very long filename that should be truncated for sure.mkv
└── short.mkv
Would be transformed into (with a truncater limit set to 24):
./
├── A very long directory na
│ ├── And another long lon.mkv
│ ├── And another long lon.srt
│ ├── A very long filename.mkv
│ ├── .rclone.short
│ └── short.mkv
└── .rclone.short
Here I chose to truncate the filenames without extension, to keep consistency between the .mkv and .srt files.
Of course, we would have to handle the tricky stuff, like having 2 different files (and same extension) being truncated to the same prefix, or already having a .rclone.short file, ...
As a bonus, we could also think about replacing special characters and use a baseXX encoding or so, but that would probably be a version 2...
Although I'm no Go expert, I have some experience in coding, and from what I saw from the existing backend code (I looked at chunker), it should be quite feasible, as basically we would only deal with FS listing.
And I must say the "contributing" page is very comprehensive!
What is your opinion about it? Do you think this would be a relevant addition, and not too difficult to implement? Or did I miss some caveats?
Thanks.