<, > and illegal characters in filenames

Ability to modify some files does NOT imply the ability modify any file,

On RISC OS it pretty much does, for in order for your idea to work, you really need to be running on the local machine to not only detect where the mouse is to know what files need shifting, but also to call the Filer to update its view. Just changing something on another machine is no guarantee of RISC OS’ view changing, and if it did – and you had no indication of what the user was doing or what windows were open, you could easily have a situation where a filer window keeps updating itself as files move around in the hope that it gets lucky and tricks the user. You know, the user who if they have a brain will think “WTF?” and disconnect.

In short, the described attack only makes sense if it is running locally. And by then it can do what it likes.

Not if it changed outside of the RISC OS instance in question since the directory was listed.

This is simply using weaknesses in the protocol. It’s the same for Windows XP (maybe others) in that connecting a remote share as a drive letter (like Z:\) often doesn’t update in Explorer until you hit F5. In one instance, I’d shut down and turned off a PC, and the other machine hadn’t noticed.

In newer terms, modern Android phones use MTP to provide a filesystem agnostic view of storage. This can be abused in much the same way in that deletions had using the phone likely won’t show up on the attached computer until some activity is performed which causes a refresh.

However, again, the chances are fairly slim that performing such a change to a file as doubling its size may be performed between asking the filesystem for the file’s size and then blindly loading it in. Not impossible if the FS returns a cached value instead of checking, but slim nonetheless.

In fact – straw poll. How many people use OS_File 12/14/16/255 to load a file, and how many GBPB it?

GBPB +1

In fact – straw poll. How many people use OS_File 12/14/16/255 to load a file, and how many GBPB it?

OS_File 16 here. I check the file size, allocate that much buffer and then load it as a block into that buffer. Is this wrong?

Is this wrong?

Depends. How big is your alu-foil hat? :-P

Depends. How big is your alu-foil hat? :-P

I’m happy that the chance of the filesize changing in between half a dozen lines of BASIC is pretty negligible. Is there a speed hit in loading it by OS_GBPB rather than OS_File? I’m usually loading in around 2MB of data.

For files that are a reasonable size, I frequently use OS_File to load (after finding its size). For larger files, OS_GBPB, or GET$# for line-based files.

There is a difference between prudence and paranoia.

• If you’re confident, OS_File,255
• If you’re prudent, OS_File,5; OS_File,16
• If you’re paranoid, OS_Find,&6F; OS_Args,2; OS_GBPB,3; OS_Find,0

I appear to be only prudent.

Getting back to the subject of the ^ character, I am reading a PDF on HP DEC VMs unixlib C runtime library (C RTL)

Unicode Support
The C RTL now supports Unicode, UTF-8 encoding for filenames given in UNIX style. For example, the following filename is now allowed:
/disk/mydir/^U65E5^U672C^U8A9E.txt filename
This greatly enhances the UNIX portability of International software that uses UTF-8 encoded filenames.

The “space filename” bit looks like a typo.

I would expect that filename to appear in RISC OS as <some prefix>.disk.mydir.<&E6><&97><&A5><&E6><&9C><&AC><&E8><&AA><&9E>, filetype &FFF (hex bytes for clarity).

The (rather unusual) ^U prefix introduces a four digit Unicode number, which must then be represented in UTF-8. So the circumflex should not end up “on disk” in that case.

XKCD today

Under RISC OS I’d hope it would appear as a proper UTF-8 filename, since there’s nothing in FileSwitch to prevent top-bit-set characters from being used.

XKCD today

Quirky 2048 text too (assuming everyone’s browser shows that.)

Under RISC OS I’d hope it would appear as a proper UTF-8 filename

I hope you didn’t misunderstand my use of GSTrans format within the context of this thread.

That’s exactly what I was trying to say.

Quirky 2048 text too

Displays ok in RISC OS :->

Looks like Hands in prayer, Helicopter, Military medal, Emoji modifier.

Under RISC OS I’d hope it would appear as a proper UTF-8 filename, since there’s nothing in FileSwitch to prevent top-bit-set characters from being used.

If this style became a common occurrence I guess you could treat everything after and between ^U’s up until . / or end of string to be converted to top set characters.
There is still the possibility of a name like ^Universe to deal with, either convert to topset characters anyway, or change the ^ to something else. If the ^U unicode expression is not used much, changing the character would be simpler to program.
The case of ~ going back to the linux world is complicated by distributions interpretation, The Ubuntu clan require ~/ to specify the home directory, and I think plain Debian is OK with just ~.
But the Zap people who used ~filenames weren’t thinking of home directories in RISC OS and I think it is a case of substituting the character to another readable character that can be viewed by other platforms and converted back for RISC OS. Naturally it makes sense to avoid using such characters in the first place, but while they are legal, you have to deal with them.

Quirky 2048 text too

Displays ok in RISC OS :→

What about the text when you hover over the cartoon panel, I haven’t got a network connected Netsurf loaded machine up and running so I’m not sure what displays.

…thanks @unicode for ruling in our favor and sending troops to end New Hampshires annexation

What about… Netsurf

Well, not right now, no. It would probably work in Lynx (here) though!

I’m getting close to a release of the “UTF-8 outside the desktop” stuff (which actually means UTF-8 everywhere), but I’m aware that it will mean that the long-overdue PostScript support will become even more urgent… and that’s probably going to have to be my problem, under the circumstances. :-/