[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Non-LFN Utilities Problem with LFNs in Xy4-DOS
- Subject: Non-"LFN Utilities" Problem with LFNs in Xy4-DOS
- From: "Robert Holmgren" holmgren@xxxxxxxx
- Date: Wed, 18 Feb 2004 11:31:29 -0500
This has nothing to do with my LFN Utils, but it is something cautionary to
keep in mind about the behavior of XyWrite 4-DOS.
Suppose you are editing a file which XyWrite knows as MYFILE~1.TXT and the
actual underlying LFN is "MyFileConcerningSomething.txt"
Suppose you COPY it to another directory, on the XyWrite CMline, using the
native XyWrite COPY command, e.g. "COPY MYFILE~1.TXT D:\GARBAGE" (where
GARBAGE is an existing directory). Now drop to DOS and issue a directory
command: "dir D:\GARBAGE\*.txt". Was the LFN preserved? No! It was not.
The copy in D:\GARBAGE now just has the filename MYFILE~1.TXT and there is no
LFN anymore -- it disappeared.
Now, actually, I guess this *does* have something to do with my LFN Utils.
Because if you use U2's COPY command, and issue the exact same command (using a
comma, of course) -- "COPY MYFILE~1.TXT,D:\GARBAGE" -- the LFN *is*
preserved.
Keep that in mind, folks. You could be in for a big surprise if you don't.
Wierd things can happen. Suppose there is _already_ a copy of MYFILE~1.TXT in
D:\GARBAGE which has lost its original LFN. What happens then? If you use the
native XyWrite COPY command, you are asked for overwrite permission. But if
you use the LFN Utils, it does what is logical: it creates a second version of
MYFILE~1.TXT under filename MYFILE~2.TXT. Then you end up with _two_ different
versions of the same file in D:\GARBAGE:
10/16/2003 10:31a 337 MYFILE~1.TXT
10/16/2003 10:31a 337 MYFILE~2.TXT MyFileConcerningSomething.txt
So the moral of this story is: don't MIX the two kinds of commands! Stick
with one system. If you're CAlling with the native command, then COPY with the
native command (but with the aberrant result that the LFN is *NOT* preserved).
If you call with CA and copy with COPY, the LFN is preserved
and overwrite permission is sought [see Note below] when you try to COPY over
an existing file, even if you use the SFN in your copy command. Confusing? I
guess. But... try to remember it.
[Note: Actually, at present, overwrite permission is not sought. I've always
resented being asked whether I want to do something that I just told the system
to do -- why did I ask to do it if I didn't want to do it? But I'm going to
reverse that decision and implement the following, which mimics XyWrite's
native command structure:
Three kinds of COPY commands:
COPY
COPY/NV [NoVerify -- no permission sought]
COPY/MV [== DOS's MOVE command]
I'll post that by tomorrow morning in LFN.ZIP, after one other fix is
implemented, which should also workaround Manuel's high-order filename problem
too. That's the way it goes when you're testing a program: gotta keep DLing
new versions.]
-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------