On Tue, Jun 10, 2008 at 08:57:26AM +0100, Ed Avis wrote: > Are filenames with spaces legal on RISC OS? I thought you had to use > non-breaking space, character number 160, instead. Shouldn't HostFS > translate character 32 to 160 when giving filenames to RISC OS, and back > again?
ASCII 32 spaces aren't legal in RISC OS. Translating back and forth seems to me to be the best policy - because of charset issues (in some encodings outside ISO8859-* and Windows-125x 160 isn't a non-breaking space) it probably isn't safe to have 160s in filenames. 160 is safe in RISC OS 3 and 4 (and 5 if in a LatinX alphabet). 32 is safe in Unix and Windows. 160 isn't a valid UTF8 or UTF16 character so may cause trouble on those systems. I may have missed something in the code - does RPCEmu translate characters it finds in filenames? Other dodgy characters ($&@%), as well as Unicode names, would need translation. As regards long filenames, this is a misunderstanding many people have. Long filenames are not a Windows 95-style wholesale change to the OS. RISC OS 3 is quite happy to cope with long filenames - really the limit is the pathname which can't be more than about 200 chars or various apps complain because WIMP messages get overfull. The constraints are that FileCore on RISC OS 3 doesn't support >10 char names and 77 entry directories, so it's not possible to have these on ADFS, SCSIFS, IDEFS etc discs. Additionally RISC OS 3.1's Filer only displays the first 10 chars of names, but will still work with long names. Long names have always been supported on non-FileCore FSs such as NFS and NetFS, back to RISC OS 2. These are managed by FileSwitch alone, and should have no problem working on older OSs. I haven't tried it, but imagine you can boot RO3.6 on RPCEmu and have long filenames in HostFS? There's a second-order effect was that some software authors (for example CC with Impression) made the assumption that names were only 10 chars and thus only allocated 10 bytes in their structures or gave an error if long names were used, but those have mostly been ironed out by upgrades to software. Theo _______________________________________________ Rpcemu mailing list [email protected] http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
