Re: XCOPY and the read-only attribute
Jonathan de Boyne Pollard
> it will clear the read-only attribute of a file. Why does it do that?
> If unintentional, then it must be a bug.
>
It's intentional. It's not a bug. It's a by-design wart. It's DOS
Think: doing things the way that PC-DOS/MS-DOS did them even though (in
this case) even PC-DOS/MS-DOS has stopped doing them that way. Go back
to PC-DOS/MS-DOS, and you'll find that XCOPY originally didn't preserve
file attributes. It was only with the advent of XCOPY32, in DOS-Windows
9x, that this capability came along. The /K ("Keep attributes") option
that came along with XCOPY32 preserves the read-only attribute. XCOPY32
was the Win32 version of the command, which was given extra features
over the MS-DOS command. XCOPY was retained in parallel, with the
MS-DOS semantics. (There were some complexities to this that I'm
glossing over since they aren't relevant.) With Windows NT, there was
and is only the Win32 version, simply named straight XCOPY.
OS/2's XCOPY, which remains a Family Mode 16-bit command to this day,
never progressed beyond its PC-DOS roots in this way.
One of the reasons that I never bothered making a 32-bit replacement for
XCOPY is that it is full of such idiosyncrasies. It's a lot simpler to
just wean onesself off XCOPY and consign its use to the dustbin. A
relatively sane COPY command is easier to use, and has command-line
options the same as other commands such as DIR or DEL. If I want to
copy an entire directory tree, preserving file attributes and including
all files whatever their attributes, I for one just use
COPY /S /A: Source\ Target\
That works with my 32-bit Command Interpreter (using either of the
provided alternatives for the COPY command) and works with 4OS2 too.