The Icon Bar: Programming: The Un-File
| |
The Un-File |
| |
swirlythingy (16:48 14/5/2011)
MEmerton (21:41 14/5/2011)
|
| |
|
Martin Bazley |
Message #117734, posted by swirlythingy at 16:48, 14/5/2011 |
Posts: 460
|
So, I downloaded this tracker file, which was named, because the author was a bit neurotic, "<-___</L/O/W!/>___->". (It's here if you want to learn from my mistake.)
As part of the web-to-hard-disc conversion process which I have written an automated program for, it tries its hardest to detect hex codes inserted into the filename by NetSurf, preceded by underscores (which were formerly percentages), and replace them with actual characters, if they are valid on RISC OS.
Now, AFAIAA, "<" is a valid filename character on RISC OS. So is ">" (which StrongHelp uses for redirects). The fun starts when you get them both together...
My first attempt at converting the filename produced "___->". This baffled me slightly, and I inserted lots of PRINT statements into the filename parser to see what was going wrong. The answer was, apparently, nothing - a flawless conversion was spat out. I probably should have given up then.
After that, I wondered if some of the unpleasant shapes I had bent OS_GSTrans into in order to accommodate my code to detect the filetype from an Amiga-style file prefix might be to blame. So I proceeded to bend it into even more unpleasant shapes.
In the end, I had a Do before each line of the obey file, and the system variable that formed the leafname translator's output had a | before each <. The translator itself detected when it was about to output a <, and prefixed it with another |. This was all in the name of making sure that, no matter how many times the filename may be translated while gzip did lawd-knows-what to it in its funny Unix sort of way, OS_GSTrans would never manage to get its filthy little mitts on the filename itself.
In this way, I finally managed to bamboozle the combined intellect of gzip and FileCore into writing a file with the correct name.
Success!
...Or so I thought.
Apparently there was a very good reason it was so difficult to get that done. It was because I wasn't supposed to be able to.
Now, as previously mentioned, < and > are perfectly valid filename characters. This was, in hindsight, a somewhat regrettable decision when combined with a towering filing system edifice which obsessively GSTransed the filename at every conceivable level... and sometimes, as I found out, bypassed the official mechanism altogether in favour of a more limited one.
In other words, what I had produced was not a tracker file, but a gaping, soulless, invincible, eternal, sucking void of an un-file, screaming blasphemy against the concept of filing systems, and an affront to the very nature of being itself, defying my every attempt to scrub it from the fabric of space-time it had corrupted.
The first hint I got that things may not have gone entirely according to plan came when, still unsure that the file contained sensible data, I Shift-double-clicked on it. StrongED produced the unexpected error "File not found". Dragging it to StrongED's icon had the same outcome.
Then I double-clicked on it to load it into DigitalCD. This did nothing whatsoever.
By now suspecting that I may have been unwise, I decided to delete the file and start again. Thus Filer_Action jumped in on the act, with "Error when deleting '___->': not found".
This was getting serious. Was it, I wondered, a Filer_Action quirk? I opened a TaskWindow, typed "Delete " and Shift-dragged in the offending file (which, it must be pointed out, displayed and was processed by the Filer impeccably at every stage). This also inserted the leafname "___->". Why? What conceivable reason is there to use OS_GSTrans if, by definition, the file comes from an already resolved location?
So I typed the filename in manually instead, and was rewarded with exactly the same error as Filer_Action. In other words, in the course of performing one operation, the filename had already been GSTransed at least twice.
So I typed it in manually again, only this time I escaped the < characters as |<, reasoning that this should defend it against any more rogue SWIs. It had absolutely no effect except to complain about a missing file named "|___->". This rather suggests OS_GSTrans wasn't involved at all, which is a rather phenomenally silly thing to do. Could Conway's Law be to blame?
I decided the time had come for dirty tricks. Possibly it only GSTransed the filename you passed to it, and not anything else it derives from that? It would certainly make sense, given that OS_GBPB is designed to remove wildcards, not insert them.
I moved everything else out of the tainted directory (just in case a simple rename would have screwed up), made sure everything was standing well back, and prepared to detonate.
It didn't go so much with a bang, as with a whimper. This was on the part of Filer_Action. I watched in astonishment, as the deletion counter for this single directory containing -1 file ratcheted up and up. One hundred... two hundred... five hundred... and though it was slain a thousand times over, and Filer_Action was relentless in its persistence, its focus and filename display never wavering, still the unholy dark beast laughed at me mockingly, the hopelessly mis-aimed blows at "Keith303.___->" glancing off its GSTrans-impenetrable hide time and time again.
By this point I was just about ready to give up and resign myself to 700KB worth of hard disc space lost (it was quite a large tracker file). I didn't know what I'd do when the time came to regenerate my DigitalCD playlist, or when I wanted to sync the new additions with my other computer. Was I forever doomed to eternal "No, not that one, deselect that, always remember to search for that before you do anything, bit of a bugger but there you go, at least it's mostly automated, now am I quite sure I haven't forgotten anything important?"? But then I had another brainwave.
What do you fight fire with? Why, fire, of course.
So, extrapolating from this miserly sample size, what do you use to fight an eternal, insatiable, sucking void, where none can survive?
One pathname presented itself to me.
A straight delete may not have worked... but how about a copy-and-delete?
In an ideal world, I would have renamed it, but sadly I was caught out by the 'No FS interbreeding' rule. I considered it a million-to-one possibility that this routine might just have been implemented slightly - crucially - differently from the ordinary delete. Would I be safe from the ever-present threat of OS_GSTrans? It was a million-to-one chance. It was a certainty.
I'd have to play my cards carefully - typing filenames straight just escaped them. Could I rely on *Copy not abusing the whole point of OS_GBPB as Filer_Action did?
Holding my breath, I typed:
Copy Keith303 null:$ D
And lo, the CLI responded:
Move directory Keith303 as null:$ (Y/N/Quiet/Abandon) ? y
Move file Keith303.<-___</L/O/W!/>___-> as null:$.<-___</L/O/W!/>___-> (Y/N/Quiet/Abandon) ? y
File Keith303.<-___</L/O/W!/>___-> moved as null:$.<-___</L/O/W!/>___->, 729 Kbytes
Directory Keith303 moved as null:$, 729 Kbytes
1 file moved, total 746316 bytes
The day was saved. I didn't have to give up 700KB after all, and untold quantities of my valuable future time would no longer have to be spent.
So, there's the moral of the story. Be careful about how you obtain your music. And never forget: if you don't want to pay the price, you can always copy it. |
| |
 [ Log in to reply ] |
| |
|
Michael Emerton |
Message #117747, posted by MEmerton at 21:41, 14/5/2011, in reply to message #117734 |
Member
Posts: 75
|
Sweet! |
| |
[ Log in to reply ] |
| |
|
The Icon Bar: Programming: The Un-File |
