Fixed LFN Utilities at XyWWWeb (LFN.ZIP)

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from "Robert Holmgren"  on Wed, 18 Feb
2004 11:31:29 -0500

Download a new LFN.ZIP at

 http://users.datarealm.com/xywwweb/LFN.ZIP

Several significant changes:

trap all non-existent files (instead of crashing the program, as formerly)
COPY command now requests overwrite Y/N verification
add COPY/NV [NoVerify] command
add overwrite protection to COPY/MoVe command
acceleration in parts of the code

One error I made was to assume that XyWrite directory displays are always
accurate. In principle, this is true. If XyWrite cannot CAll a file, then it
does not display it in a DIR screen -- e.g., Hidden files are excluded from
XyWrite DIR displays because Xy can't CAll them.

But there are several ways that a Xy4 DIR display can be rendered inaccurate.
One is the everyday situation where user creates a DIR display, then _manually_
(on the CMline) DELetes a file. The DELeted file is still shown in the
directory display. If user then runs DIRLFN, when the program reaches the
deleted file, it goes into an endless loop. Fixed.

Another situation is somewhat rarer. Some external programs (and operating
systems) create files with 8.3 names that are illegal under the original DOS
rules. For example, they might contain spaces: "EA DATA. SF" is a famous
example. Usually that's a Hidden file, but if you move it from one operating
system to another, it can lose the Hidden attribute. Because XyWrite
interprets a space to be the end of the "filename" part of "filename.ext" (or
the "ext" part of "filename.ext"), a Xy4 DIR display would report this file as
just "EA". But no file "EA" actually exists, resulting in an endless loop.
Fixed.

I haven't yet gotten any examples from Manuel of high-order characters in
filenames, but I _think_ that the changes I've made will workaround such
filenames -- we'll see soon enough.

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