If I understand correctly, FileSysbox should handle the translation from UTF-8 to the local (latin-1) charset. Does this also work on AmigaOS 4?
I have a share with some non latin-1 chars (music files) that only works correctly with smbfs (the old one) on AmigaOS 4. Both ssh2-handler and smb2fs-handler cannot handle the UTF-8 filenames.
Filesnames are correct with the latest filesysbox and smb2-handler on my Amiga with a 68020 and AmigaOS 3.2.1.
Filesysbox.library has the version 54.9 on my Amiga X5000.
For AmigaOS 4 charset conversion was added in version 54.12 of filesysbox.library that was released to beta testers only just under two weeks ago (6.1.2023).
For AmigaOS 4 charset conversion was added in version 54.12 of filesysbox.library that was released to beta testers only just under two weeks ago (6.1.2023).
That doesn't make any sense, on AmigaOS 4.x FileSystems must not convert charsets, unless it's a Windows/MacOS/etc. filesystem (FAT, HFS, NTFS, ...) which uses charsets which are impossible on AmigaOS and have to be converted to UTF-8. Instead the applications have to do it (Workbench, ASL, Dopus, Filer, etc.) for displaying the file/dir names in the currently selected local charset. The only acceptable charset in file names on AmigaOS 4.x is UTF-8 (maybe UTF-7 too, I don't remember if that was allowed as well), and as fallback for old files/dirs (created on AmigaOS 3.x or older) only ISO-8859-15 (not 8859-1). If a file/dir name includes chars in the [128-159] range it's a new file/dir with UFT-8 encoding, if it doesn't it's an old, ISO-8859-15 one, or one without any non-ASCII chars.
AmigaOS does not support UTF-8 and that is unlikely to change any time soon.
Should a miracle happen and this situation changes at some point it is just a matter of removing/commenting out a line in the filesysbox makefile to disable the UTF-8 to/from local charset conversion.
Unlike the old attempt at charset conversion this one: 1. Queries what charset is used on the system and uses the unicode maptable for that charset. 2. Unicode values that can't be converted into the local charset are converted into base32 escape sequences that can be converted back into the original UTF-8. 3. Conversion only happens when strings are passed between AmigaDOS and filesysbox. Internally filesysbox uses only UTF-8 file names.
I implemented it because I got tired of literally everyone's initial reaction to trying a FUSE file system being to ask why it doesn't handle UTF-8 characters, even though it handles them just fine (just nothing else did or does).
AmigaOS does not support UTF-8 and that is unlikely to change any time soon.
utility.library, and it's replacement functions patched after locale.library is loaded, include UTF-8 to local charset conversions, and the other way round, since about 20 years already. At the time I was still in the AmigaOS 4.x team, which is about 15 years ago already, it was specified that filesystems have to use UTF-8 and the applications have to do conversion for input and output instead. Maybe they changed their mind, but any other solution doesn't make any sense at all.
I am aware of those functions as they were based on ones I use in my filesysbox. A couple of functions for decoding and encoding UTF-8 characters (that programmers can choose to use or not) does not mean that the OS supports UTF-8 though.
Decoding and encoding UTF-8 sequences has never been a problem on AmigaOS really (even before utility.library support there were several 3rd party libraries available for this, as well as the functions in newlib).
The most important thing that is missing IMO is that there is no way to actually render UTF-8 or unicode using the standard graphics.library text functions. The only way to do so currently is to ignore graphics.library and use the low level bullet interface directly which is really tedious and doesn't work well as a general solution for applications. Until this is solved there is no point in trying to use UTF-8 in locale catalogs as those characters will not render correctly in pretty much any applications at all.
The most important thing that is missing IMO is that there is no way to actually render UTF-8 or unicode using the standard graphics.library text functions. The only way to do so currently is to ignore graphics.library and use the low level bullet interface directly which is really tedious and doesn't work well as a general solution for applications.
In OWB I used the new AmigaOS 4.x diskfont.library outline font functions and didn't have any problems rendering unicode texts with them.
Yes I was talking about SMB2, they work well, see my screenshot, with my AROS One x86, but even with OS3 I created multiple connections to shared and public
The def icons also appear automatically, after clicking on the mount icon
I see the handler is maturing very fast.However i noticed that i cannot select a share using the backup tool from Daniel@onyxsoft on either source or destination ASL requesters.Tested from versions V53.2 up to the current 53.4 one.Cannot remember if it happened as well on V53.1
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
