I hope for an auto transcoding feature in SyncThing.
Mac an LINUX (hereby NIX/NUX) users can use characters in file names that Windows users cannot.
That is perfectly fine as long as you don’t mix NIX/NUX with Windows. But some companies or families do or need to do.
I hope the developers of SyncThing would reconsider adding auto transcoding support to SyncThing. This way, forbidden characters in file names are automatically converted based on platform: Windows, NIX/NUX. The idea is that forbidden characters are platform specific replaced by allowed lookalikes during sync or copy transactions while maintaining the original name of the source file.
I know you can enable auto transcoding to rclone by adding this to its config file:
encoding = Colon,Question,DoubleQuote,Asterisk,LtGt,Pipe,BackSlash
Ditto for SAMBA via its CATIA module by adding this to the samba server config:
[global]
vfs objects = catia fruit streams_xattr
catia:mappings = 0x22:0xa8,0x2a:0xa4,0x2f:0xf8,0x3a:0xf7,0x3c:0xab,0x3e:0xbb,0x3f:0xbf,0x5c:0xff,0x7c:0xa6
But rclone nor SAMBA do not help SyncThing when used in a mixed environment and IMHO make things too complicated for non technical end users. Hence my kindly request to the developers of SyncThing to support auto transcoding. I guess I am not the only one who came across this challenge.
The problem I see is making it bidirectional. Suppose System A allows “æ” but System B doesn’t. So A translates it to “ae”. That’s pretty common. But how does System B know when to translate “ae” to “æ” and when to leave it intact? You could reduce the false translations by adding some uncommon quotes, such as “!ae!”, but all you’ve done is made the problem less common. It hasn’t really been solved, and because you have to pick some valid character for the quoting, it’s bound to be used by someone sooner or later. You can’t just leave it to chance.
System A transmits æ to System B. System B knows it can’t save files with æ in the name, so it encodes it. When it reads the filename, it decodes it back into æ.
Doesn’t ST know the file came from a different source? I guess it would get trickier if the file with the transcoded filename was moved on the side where it was transcoded.
but if it was transcoded upon receipt then that system should be able to remember that it was transcoded and can transcode back before communicating with any other system.
we also have send or receive only folders where there’s no complication regarding whether the filename was transcoded. (As far as I can conceive at the moment.)
That’s an idea. Many many years ago, I worked on some system which had to translate file names, but I remember no details, just that making it work in both directions was a real pain. Now throwing in multiple systems … I have this dread I can’t articulate, of A transcoding to B which transcodes to C which transcodes to A and it ends up different. Maybe I’m worried over nothing. It was a long time ago, before Unicode I’m certain. Maybe it was some upper/lower problem.
I just figure we store metadata with a file. Maybe we store the original filename. It’s a naive comment because I don’t really know how the metadata is stored but I just figure if a local system needs to transcode a filename to store it, then the local filesystem should be the only one that needs to know what the original filename was. And all communication with the other nodes can be in the context of the original filename. So other systems don’t even need to be aware that some remote system transcoded a filename and perhaps can be so ignorant of it they even can run some old syncthing version that doesn’t have the transcoding capability.
again there is some devil in the details in terms of file edits. But it seems reasonably possible.
Doesn’t the metadata of the original file name have to travel with it? Otherwise A —> B —> C could come back as a different file name and not be detected as the original, and end up with a changed copy with a different name.
In your example if only B needs to transcode, then A and C talk with the original filename. But when A talks to B, B transcodes the file on B’s side only. So B still talks back to A with the original filename. And then when B talks to C, B also remembers the original filename, so B talks to C ALSO with the original filename.
C doesn’t ever know that B is transcoding the filename. Neither does A.