>
char[char][char][char][char][char][char][char](.)[char][char][char]
On Mon, 12 Dec
2011, John Willis wrote:
I'm
reminded of an old trick from the days of DOS 3.2... keep
people from tampering
with a file by embedding an 0xFF character in the
name... perfectly legal name, but appears in a DIR listing as a space.
One of those security-through-obscurity things.
Since we are talking about the ACTUAL filenames, as present in the disk
DIRectory and as used in the File Control Blocks in memory, as opposed to
the REPRESENTATIONS used in communication with the user by the CLI (which
resulted in some well-intentioned person thinking that I had gotten the
structure wrong), it is certainly easy to break many of the "rules" of the
DOS filenames, at the risk of "undefined" (but FUN) results.
Character 127 is another one, as are many (most?) of the "extended"
characters.
If you go in and step on the DIRectory on the disk, you can do all sorts
of fun things.
Such as:
creating a file named "*.*", or "????????.???"
or creating a subdirectory entry for one's own parent, grandparent, or
further directory, putting CHKDSK /V and "find-next" into a loop
or creating a file with a -2147483648 byte file size (unfortunately,
copying such a file to an almost full disk does NOT increase the free
space)
or marking a DIRectory entry as "never used", thus hiding subsequent
entries
or marking the boot sector as SS on a DS diskette (the trivial copy
protection on XenoCopy-PC that completely unprotects once somebody has
given their name to be stored in the title screen of the program)
or creating a filename that will confuse the handling of Long File
NICKnames.
or '\' in a DOS 1.xx disk
or '/', '-' etc, that will confuse some CLI operations and/or programs
('+' confuses the hell out of COPY, but doesn't bother most other
operations)
or '/' in a filename on a machine on WWW (which uses Unix subdir
separators)
