Discussion:
XCOPY and the read-only attribute
(too old to reply)
t***@antispam.ham
2011-04-08 22:04:12 UTC
Permalink
Raw Message
I've been using XCOPY for some backup purposes, and I've noticed
that it will clear the read-only attribute of a file. Why does
it do that? If unintentional, then it must be a bug.
Lars Erdmann
2011-04-09 13:57:58 UTC
Permalink
Raw Message
Question:

are you copying on the same volume ("drive letter") or across different
volumes ("drive letters") ?

I would have to look at OS/2 IFS specification but I could image that if you
copy across the
same volume that then all attributes are preserved (as there is I think a
special file system entry point
to handle copies/moves on the same volume, possibly for reasons of
maximizing performance. In the case
of "move" this is the obvious reason as you might just need to "relink" file
system structures but can leave
the actual file where it is.)
For different volumes a copy is a "read A" and "write B" process and move
would be a
"read A", "write B", "delete A" process.

If what I suspect is true, then XCOPY works as expected. You might however
think that OS/2
filesystem design does not work the way you would expect it to work.

By the way: have you tried COPY ? What does it do ?

Obviously, an application might decide to update the file attributes of the
target copy on its own.


Lars
Post by t***@antispam.ham
I've been using XCOPY for some backup purposes, and I've noticed
that it will clear the read-only attribute of a file. Why does
it do that? If unintentional, then it must be a bug.
t***@antispam.ham
2011-04-10 02:38:19 UTC
Permalink
Raw Message
Post by Lars Erdmann
are you copying on the same volume ("drive letter") or across different
volumes ("drive letters") ?
Different. I'm using it for backup purposes, so I want to replicate my
files on completely different physical media.
Post by Lars Erdmann
I would have to look at OS/2 IFS specification but I could image that if you
copy across the
same volume that then all attributes are preserved (as there is I think a
special file system entry point
to handle copies/moves on the same volume, possibly for reasons of
maximizing performance. In the case
of "move" this is the obvious reason as you might just need to "relink" file
system structures but can leave
the actual file where it is.)
For different volumes a copy is a "read A" and "write B" process and move
would be a
"read A", "write B", "delete A" process.
If what I suspect is true, then XCOPY works as expected. You might however
think that OS/2
filesystem design does not work the way you would expect it to work.
By the way: have you tried COPY ? What does it do ?
COPY doesn't recurse into subdirectories. I'm using XCOPY to backup
an entire partition. XCOPY is smart enough to avoid recopying files
that have already been copied once, so only the initial backup is
time consuming. Incremental backups are fast. No, I don't want to
use the BACKUP command. That forces the use of RESTORE, and it's
not nearly as user friendly as simply seeing an entire partition
mirrored on another physical drive.
Dave Yeo
2011-04-10 02:42:36 UTC
Permalink
Raw Message
Post by t***@antispam.ham
Post by Lars Erdmann
are you copying on the same volume ("drive letter") or across different
volumes ("drive letters") ?
Different. I'm using it for backup purposes, so I want to replicate my
files on completely different physical media.
You should use the options /h /o /t /s /e /r /v. I've never had readonly
files changed to read+write that I noticed.
You could also look at using rsync for mirroring a drive.
Dave
t***@antispam.ham
2011-04-10 14:16:13 UTC
Permalink
Raw Message
Post by Dave Yeo
Post by t***@antispam.ham
Post by Lars Erdmann
are you copying on the same volume ("drive letter") or across different
volumes ("drive letters") ?
Different. I'm using it for backup purposes, so I want to replicate my
files on completely different physical media.
You should use the options /h /o /t /s /e /r /v. I've never had readonly
files changed to read+write that I noticed.
I haven't yet tested whether /R leaves the read-only attribute alone
on the source drive. The documentation only says that it keeps it
on the target drive.
Post by Dave Yeo
You could also look at using rsync for mirroring a drive.
Well, it's not exactly mirroring. I'm backing up multiple
smaller drives onto a single big drive.
Dave Yeo
2011-04-10 17:31:56 UTC
Permalink
Raw Message
Post by t***@antispam.ham
Post by Dave Yeo
You could also look at using rsync for mirroring a drive.
Well, it's not exactly mirroring. I'm backing up multiple
smaller drives onto a single big drive.
As far as I know, rsync would work fine for that as well (each drive
backed up to a separate subdirectory.
Dave
Peter Brown
2011-04-11 00:00:37 UTC
Permalink
Raw Message
Hi
Post by Dave Yeo
Post by Dave Yeo
You could also look at using rsync for mirroring a drive.
Well, it's not exactly mirroring. I'm backing up multiple
smaller drives onto a single big drive.
As far as I know, rsync would work fine for that as well (each drive
backed up to a separate subdirectory.
Dave
Yes, that works.

I've been playing with luckybackup -
ftp://ftp.netlabs.org/pub/qtapps/luckybackup-0.4.5-os2.zip - which uses
rsync and have no problems backing up multiple drives to 1 USB drive.

Regards

Pete
Andreas Buchinger
2011-04-22 16:32:35 UTC
Permalink
Raw Message
***@antispam.ham wrote:
.....
Post by t***@antispam.ham
COPY doesn't recurse into subdirectories.
The 4os2 copy command does. copy source target /U /S /Z
/U update if file is newer or does not exist
/S going into subdirectories
/Z process read only files too

Maybe worth to try.

James J. Weinkam
2011-04-10 01:19:28 UTC
Permalink
Raw Message
Post by t***@antispam.ham
I've been using XCOPY for some backup purposes, and I've noticed
that it will clear the read-only attribute of a file. Why does
it do that? If unintentional, then it must be a bug.
The /R option causes XCOPY to retain the read only attribute.
t***@antispam.ham
2011-04-10 02:32:17 UTC
Permalink
Raw Message
Post by James J. Weinkam
Post by t***@antispam.ham
I've been using XCOPY for some backup purposes, and I've noticed
that it will clear the read-only attribute of a file. Why does
it do that? If unintentional, then it must be a bug.
The /R option causes XCOPY to retain the read only attribute.
In the target directory, according to the HELP XCOPY documentation.
The behavior I want to change is in the source directory. Files
that I had marked as read-only were being converted to read-write
by the XCOPY command. I will need to test it to see if /R also
preserves the read-only attribute in the source directory. The
documentation is silent on this point.
Jonathan de Boyne Pollard
2011-04-10 01:57:54 UTC
Permalink
Raw Message
I've been using XCOPY for some backup purposes, and I've noticed that
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.
Loading...