[x]copy bug: "title" vs "real name"

[Peter Wadsack]

I have a number of files which are updated every month, of the form
whatever-yyyymm.des

If I open these in e.g. DeScribe and save incremented, title and real name
both change, i.e.
whatever-200205.des saved as whatever-200206.des from DeScribe shows up in
the directory window with
title | real name
whatever-200205.des | whatever-200205.des
whatever-200206.des | whatever-200206.des

If, instead, I use an OS/2 window and do
[x]copy whatever-200205.des whatever-200206.des
or
[x]copy *-200205.des *-200206.des
then
in the directory window I get
title | real name
whatever-200205.des | whatever-200205.des
whatever-200205.des | whatever-200206.des

Why???

In the CLI, dir *206* gives the correct result.
In PM, using /edit/find with *206* shows nothing.

Why the inconsistency?
What is the fix?

Peter

*/------------------------------------------------------
Peter Wadsack <wad...@attglobal.net>
Wadsack Management; Madison WI USA
------------------------------------------------------*/

[Dave Saville]

As the subject of xcopy has kinda come up :-)

There is a bug in xcopy, I believe, in that it tries to determine if the target is a file or a directory
by testing the last charcter for \

If it does *not* find a \ on the end it asks which it is ( why they just can't test the file attributes....)
Anyway, consider a target that has spaces in the path - Normally one would quote the path to
preserve it as one string to the arg parser. Guess what xcopy does with this:

xcopy c:\foo 'c:\blah\some odd name\stuff\'

Yup it thinks the target is the close quote.

This means you can't use xcopy in a batch file if its targets have spaces in their path names.
'cos there aint no one to answer the damn message :-(

Regards

Dave Saville

NB switch saville for nospam in address

[James J. Weinkam]

Dave Saville wrote:
>
> This means you can't use xcopy in a batch file if its targets have spaces in their path names.
> 'cos there aint no one to answer the damn message :-(
>

Sounds like a bug for sure, but as far as answering the message goes, you can
handle this in a command file by creating a file containing the appropriate
reply (or replies if more than one question will be asked) and redirecting
this to standard input on the command line in question.

[Dave Saville]

Hmm, I might try that but I have almost programmed around it by now anyway.

[Meinolf Sondermann]

Peter Wadsack wrote:

[...]

> [x]copy whatever-200205.des whatever-200206.des
> or
> [x]copy *-200205.des *-200206.des
> then
> in the directory window I get
> title | real name
> whatever-200205.des | whatever-200205.des
> whatever-200205.des | whatever-200206.des
>
> Why???
>
> In the CLI, dir *206* gives the correct result.
> In PM, using /edit/find with *206* shows nothing.
>
> Why the inconsistency?

The "Title" is stored in the extended attributes under .LONGNAME.
"copy" and "xcopy" duplicate the EAs as well. So the real name
and the long name go out of sync.

You could write a REXX procedure to get them in sync, using
SysGetEA and SysPutEA from REXXUTIL.DLL.

But there are some characters allowed in the long name that
are illegal for real names. E.g. a CRLF ('0D0A'x) in the
long name gets translated to '!!' ('2121'x) in the real name.

--
Bye/2
Meinolf

[Meinolf Sondermann]

Dave Saville wrote:

> As the subject of xcopy has kinda come up :-)
>
> There is a bug in xcopy, I believe, in that it tries to determine if the target is a file or a directory
> by testing the last charcter for \
>
> If it does *not* find a \ on the end it asks which it is ( why they just can't test the file attributes....)
> Anyway, consider a target that has spaces in the path - Normally one would quote the path to
> preserve it as one string to the arg parser. Guess what xcopy does with this:
>
> xcopy c:\foo 'c:\blah\some odd name\stuff\'
>
> Yup it thinks the target is the close quote.

First: Don't use single quotes but double quotes.
Single quotes are allowed for file names.
Then just omit the closing quotes, and XCOPY works.
Or put only parts of the target in quotes:

xcopy c:\foo c:\blah\"some odd name"\stuff\

works as well.

--
Bye/2
Meinolf

[Scott]

"Meinolf Sondermann" <mer...@attglobal.net> wrote in message
news:3D0326F8...@attglobal.net...

Meinolf, that was an excellent explanation. Thank you. About once a year,
someone discovers this and (usually) insists that it's a bug. Oh, well.

[Scott]

> There is a bug in xcopy, I believe, in that it tries to determine if the
target is a file or a directory
> by testing the last charcter for \
>
> If it does *not* find a \ on the end it asks which it is ( why they just
can't test the file attributes....)
> Anyway, consider a target that has spaces in the path - Normally one would
quote the path to
> preserve it as one string to the arg parser. Guess what xcopy does with
this:
>
> xcopy c:\foo 'c:\blah\some odd name\stuff\'
>
> Yup it thinks the target is the close quote.
>
> This means you can't use xcopy in a batch file if its targets have spaces
in their path names.
> 'cos there aint no one to answer the damn message :-(

Note Meinolf's workaround (omitting the trailing quote). The "why they just
can't..." is because "it's always worked
that way." I can 100% guarantee that if I were to change the behavior as you
suggest, that it would break a REXX script at one of our large customers'
sites. Your idea is a good one, and had I seen it ten years ago, I would
have suggested that xcopy do just that. Now, it's just too late.
-scott

[William L. Hartzell]

Sir:

Scott wrote:
>
> Meinolf, that was an excellent explanation. Thank you. About once a year,
> someone discovers this and (usually) insists that it's a bug. Oh, well.
>
>

What would be neet is some api that regularize this 'problem' into a
useful function, ie a set 'title', change 'title', restore 'title to
real name', and report 'real name for title'. This would allow real
aliases?
--
Bill
<For all of yours, Father's Day>

[Peter Wadsack]

On Sun, 09 Jun 2002 13:55:09 GMT, Scott wrote:

:>
:> "Meinolf Sondermann" <mer...@attglobal.net> wrote in message

:>
:>

Yes, it is an excellent explanantion; I can now work around the "feature".
Or is it an "issue"?, since I'm not allowed to call it a "bug".

At least, I would expect that creating a copy via CLI and via PM would yield
the same result. Oh, well.

[Dave Saville]

I think the single quotes were a typo - so used to rexx where it does not matter.

The invocation is inside a batch file - I don't necessarily know where the spaces are if at all -
hence quoting the whole thing. And the last example does not work:

[E:\tmp]xcopy e:\tmp\scan.pnm e:\tmp\rsynctest\"name with a space"\stuff
SYS1001: An incorrect parameter was entered for the command.

0 file(s) copied.

But this does work with N CR/LF in answer - with or without the trailing double quote

[E:\tmp]xcopy <answer e:\tmp\scan.pnm "e:\tmp\rsynctest\name with a space\stuff
The current target for XCOPY, stuff,
can be a directory or file name and must be specified. Respond Y
if the target is a directory or N if the target is a file name.

Does stuff specify a directory (Y/N)? N

Source files are being read...

E:\tmp\scan.pnm

1 file(s) copied.

Thanks for the idea of the stdin redirect, although it only works immediately after the
command itself, and the info that you can leave off the trailing close double quote.

But as I said, I have programmed around it now.