Re: New program: LFN Utilities for Win32

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from "Martin J. Osborne"  on
Mon, 16 Feb 2004 23:17:32 -0500

> After I did so, there remained some "{>>}" strings in the file. (I
> manually replaced them with ASCII 175's.)

Hmmm. Mine decoded perfectly. I just tried it two ways. I saved my message
(as received by Email from UPenn) in my Email client, then CAlled it into
XyWrite. In eXPanded mode, DECODEd it: identical with the original. I also
CLIPped it and PASTEd it into XyWrite using U2 frame CLIPW, eXPanded mode:
identical with the original. So there's something wrong with your methodology.
I'd try again, rather than manually doing anything and maybe missing something.
CAll in eXPanded mode! CA/100 MSG.POP or whatever...

> Do you mean MoVe?

What's the difference? Whichever. "Put" the code from the Email message into
U2 and INF, respectively.

> An initial test: Under my setup (W98SE, XyDOS 4.018)> 	ca longfilename.txt
> works perfectly, but
>	new longfilename.txt

Not a legal command. Should be NE (no "W"):
	ne longfilename.txt

> produces the mysterious message "new file not found: longfilename.txt".

I can't reproduce that. However -- I don't know if this is your problem, but I
do see, in Win95 anyway, that the redirection statement ">NUL", to send STDOUT
into the ether, doesn't work exactly as in NT. NT traps STDOUT with >NUL, but
not STDERR. Win9x seems to trap them both (really stupid -- the whole point of
STDERRor messages is not to mask them), and thus you don't see the prompts for
necessary user input -- the program seems to hang, although it's actually
waiting for a y/n keystroke. So delete *all instances* (maybe 5 ?) of the four
characters ">NUL" that appear in these four frames. Then LOADHELP to
save the changes. Suddenly you start to see the overwrite verification msgs
that you're supposed to see. Works fine here (Win95).

One other thing. I should have documented this. NEw has a subtle difference
from the native command. In the native command, when you issue NE FILENAME,
the filename opens in a window, but it is not yet written to disk -- you have
to SAve it to make it exist. In these LFN utils, a NEw file _is_ written to
disk, as 1 byte (an EOF character, Ascii-26). I have to do that, because
otherwise there's no way to ascertain what the SFN of the NEw long-named file
will be if it doesn't yet exist (ascertaining the short file name is the whole
point of these utils). So that means that if you issue a second NEw command
using the same filename, in fact it already exists, so you are asked whether
you want to overwrite it or not. Another way to look at it is, issuing a
second NEw with these utils is a way of "starting over afresh", if you so
choose (with the native command, if you issue NEw and the file already exists,
it simply prompts "File already exists"). If you elect not to overwrite, the
result is that the existing file is CAlled instead of being reinvented as an
empty NEw file.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------