On 3/14/21 4:15 PM, this is what Yes wrote:

Any idea about what is happening here? OS is Windows 8 Pro 64-bit.

I'm backing up a folder on drive e:\ to drive c:\. The source folder
is sized 1,801,834,496 bytes containing 1,725 files in 109 folders. If
I use xcopy in CLI to create it, the number of files and folders in properties window of the newly created folder on c:\ are off from that
of the source folder on e:\. If I use the GUI to copy the folder from
e:\ to c:\, there is no discrepancy.

Ya think xcopy is missing hidden system files?
Why not use robocopy <src> <dest> /MIR


--
Linux Mint Cinnamon 20.1 64bit, Dell Inspiron 5570 laptop
Quad Core i7-8550U, 16G Memory, 512G SSD, 750G & 1TB HDDs
*I collect teddy bears.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Any idea about what is happening here? OS is Windows 8 Pro 64-bit.

I'm backing up a folder on drive e:\ to drive c:\. The source folder
is sized 1,801,834,496 bytes containing 1,725 files in 109 folders. If
I use xcopy in CLI to create it, the number of files and folders in
properties window of the newly created folder on c:\ are off from that
of the source folder on e:\. If I use the GUI to copy the folder from
e:\ to c:\, there is no discrepancy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Yes wrote:

Any idea about what is happening here? OS is Windows 8 Pro 64-bit.

I'm backing up a folder on drive e:\ to drive c:\. The source folder
is sized 1,801,834,496 bytes containing 1,725 files in 109 folders. If
I use xcopy in CLI to create it, the number of files and folders in properties window of the newly created folder on c:\ are off from that
of the source folder on e:\. If I use the GUI to copy the folder from
e:\ to c:\, there is no discrepancy.

When you plug a foreign disk into the machine,
if you were to initially check it, the file would
have one "Owner".

When File Explorer looks in there as account "Yes",
it notices that "Yes" doesn't own the files and
that perhaps, access is denied in some way.

File Explorer can do a TakeOwn and change the ownership.
You'll see a file has two owners, an account "Yes"
(a new owner), but also a numeric SID which is the
ownership SID of the other computer visiting it. Only
the other computer, has a mapping of the numeric SID
it was using, to its owner.

If both machines had an account "Yes", the accounts
use different SID values. (If you were at work, on
a Corporate LAN, had a Domain server, the two "Yes"
accounts could use the same SID.)

By adding an owner, File Explorer makes it easier
to copy pure-data files (your movie collection).
If you let File Explorer visit first, and you see
the green bar in the URI bar of File Explorer, it
may be easier for xcopy to work.

Not all file permissions are "permissive" and some
things will resist the TakeOwn ("green bar") that
File Explorer uses. The System Volume Information
folder, nobody gets in there, whether a local "Yes"
or the "Yes" on a second machine.

Select a file, do Properties, Security tab and see how
many owners are present. I've had as many as four
owner SIDs on some of my data drives, for example.

Linux NTFS smashes the permissions entirely. Which means
even "tough" things can be managed. It does not change
the SID on the disk, it just ignores it while copying.

If you make a Macrium backup, you ask Macrium to "mount"
the .mrimg backup file, there's a little tick box to
"disable permissions" or similar, and it allows turning
a tough nut, into an easy thing to copy. And then you
can use xcopy if you want. For example, if I back up
all of C: to a .mrimg, then mount the .mrimg as W: ,
I can copy W: to C:, any part I might like, with my
xcopy command.

https://www.macrium.com/reflectfree # Home Use button, left side
# Version 7, enjoy while
# it is still available.

Just be careful to not go in System Volume Information
and muck about. I absolutely destroyed a Win7 install
once when I did that. And I swear, the only operations
I was doing were read operations, no writes, and the
damn thing was cooked like dinner. CHKDSK would not
save it. It was ruined. It's a good thing there was
a fresh backup in the room, to save me. Not all my
accidents, do I get that lucky.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Teddy-Bears wrote:

On 3/14/21 4:15 PM, this is what Yes wrote:

Any idea about what is happening here? OS is Windows 8 Pro 64-bit.

I'm backing up a folder on drive e:\ to drive c:\. The source
folder is sized 1,801,834,496 bytes containing 1,725 files in 109
folders. If I use xcopy in CLI to create it, the number of files
and folders in properties window of the newly created folder on c:\
are off from that of the source folder on e:\. If I use the GUI to
copy the folder from e:\ to c:\, there is no discrepancy.

Ya think xcopy is missing hidden system files?
Why not use robocopy <src> <dest> /MIR

Thanks. I'll have to first read the info about robocopy. I'm not
familiar with it. I'm so used to using copy, xcopy or the GUI to copy
files. I wasn't even aware that there was that type of command.

I'm not so sure if hidden system files are at issue. I have one folder
in which I have some deeply nested sub-folders and some files names in
it are pretty long. I worry that perhaps during the copying process
the file name may exceed the 256 char limit. I have received that type
of warning in the past and immediately renamed the file with something
shorter and then manually copying them.

From Paul's reply, I realize that I failed to note that both drives are internal hard drives on the same pc and used by the OS.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Yes wrote:

Teddy-Bears wrote:

On 3/14/21 4:15 PM, this is what Yes wrote:

Any idea about what is happening here? OS is Windows 8 Pro 64-bit.

I'm backing up a folder on drive e:\ to drive c:\. The source
folder is sized 1,801,834,496 bytes containing 1,725 files in 109
folders. If I use xcopy in CLI to create it, the number of files
and folders in properties window of the newly created folder on c:\
are off from that of the source folder on e:\. If I use the GUI to
copy the folder from e:\ to c:\, there is no discrepancy.

Ya think xcopy is missing hidden system files?
Why not use robocopy <src> <dest> /MIR

Thanks. I'll have to first read the info about robocopy. I'm not
familiar with it. I'm so used to using copy, xcopy or the GUI to copy
files. I wasn't even aware that there was that type of command.

I'm not so sure if hidden system files are at issue. I have one folder
in which I have some deeply nested sub-folders and some files names in
it are pretty long. I worry that perhaps during the copying process
the file name may exceed the 256 char limit. I have received that type
of warning in the past and immediately renamed the file with something shorter and then manually copying them.

From Paul's reply, I realize that I failed to note that both drives are internal hard drives on the same pc and used by the OS.

Be careful of the /MIR option, because that's mirror.

If the <src> was an empty folder, it deletes the contents of <dest>.

Mirror means that the destination "looks" like the source, for better
or worse. Not like an ordinary copy, which would be closer to a "merge".

In fact, /MIR has been proposed as a mechanism to delete the contents
of folders! But I would not abuse the option, because while the programmer likely worked at Microsoft, there are going to be some trees (C:\Windows.old) that are quite resistant to deletion. Similarly, asking Robocopy to
delete C:\System Volume Information (a Permission Denied folder), will
likely end in a failure with error message.

Just be careful with that /MIR. I use /MIR all the time... for a
certain purpose, but I'm aware if I make *one typing error*,
I could lose the contents of a whole partition! Dynamite!

*******

Robocopy has a lot of options, including an option to handle Junctions.

To see if a home directory has Junctions, run this command.
There are probably around 62 junctions minimum on C: at a guess.

https://docs.microsoft.com/en-us/sysinternals/downloads/junction

To list junctions beneath a directory, include the –s switch:

junction -s c:\

Then you'd know if a junction-avoidance option is needed.

If a program is unprepared for junctions, it will "trip out"
on a "Path Too Long" error, as the path keeps growing in length
inside the executable, due to the recursion (keeps trying
to evaluate the Junction and traverse it).

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 15 Mar 2021 17:57:23 -0400, Paul wrote:

Robocopy has a lot of options, including an option to handle Junctions.

To see if a home directory has Junctions, run this command.
There are probably around 62 junctions minimum on C: at a guess.

https://docs.microsoft.com/en-us/sysinternals/downloads/junction

To list junctions beneath a directory, include the ?s switch:

junction -s c:\

Then you'd know if a junction-avoidance option is needed.

The /XJ option tells Robocopy to skip junctions. Without that option,
Robocopy follows junctions and creates regular (non-junction)
directories on the target, then copies all files. So if you do
robocopy A B /S
where A and B are directories, and a subdirectory A\C (at any level)
is actually a junction to another subdirectory A\D, you'll get two
copies of all the files in D. Adding /XJ to the robocopy command
prevents that. On the other hand, if the junction points to a
directory outside of the A tree, you might actually want the copy to
take place.

I find it very hard to wrap my head around junctions versus hard
links versus soft links. This document helps:

https://www.2brightsparks.com/resources/articles/ntfs-hard-links- junctions-and-symbolic-links.html


--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
https://OakRoadSystems.com/
Shikata ga nai...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)