[v22.00.41] sync command flag "/X" does not work

#3
Thank you, Rex.

I found out with a test file that it SOMETIMES works, sometimes not ... related to drive (copy) speed somehow or so? I don't know ...

Also I have the same behaviour with the COPY command ...

But the test file was always successfully copied in all this cases!

Please note that I had this behaviour NEVER with the XCOPY console command with flag /M in the Win console prompt!

Maybe if you make enough tests - even with enough large file(s) and slow drives - you can reproducible it?

Have a good day!
 
#6
I tried this. I started with this.
Code:
v:\> attrib
___A______C_I__  V:\0.btm
___A____L___I__  V:\1.bat
___A____L___I__  V:\1.btm
___A____L___I__  V:\1.cmd
___A____L___I__  V:\2.bat
___A____L___I__  V:\2.btm
___A____L___I__  V:\2.cmd
___A________I__  V:\4.cmd
___A________I__  V:\4console.zip
___A________I__  V:\add.vb
<snip>/code]

Every file in v:\ had the archive attribute.  I gave this command; e:\synctest was empty.
[code]sync /m /x /s /y v:\ e:\synctest\
It looked OK. Here's the end of the forward copying.
Code:
SYNC: V:\ => E:\synctest\
<snip>
V:\math\squarewalk.txt => E:\synctest\math\squarewalk.txt
V:\redist8\vcredist_x86.exe => E:\synctest\redist8\vcredist_x86.exe
V:\redist8\VCREDI~1.EXE => E:\synctest\redist8\VCREDI~1.EXE
V:\redist8\VCREDI~3.EXE => E:\synctest\redist8\VCREDI~3.EXE
   160 files copied
But then it continued a little. What's this all about?
Code:
SYNC: E:\synctest\ => V:\
E:\synctest\1.bat =>! V:\1.bat
E:\synctest\1.btm =>! V:\1.btm
E:\synctest\1.cmd =>! V:\1.cmd
E:\synctest\2.bat =>! V:\2.bat
E:\synctest\2.btm =>! V:\2.btm
E:\synctest\2.cmd =>! V:\2.cmd
     6 files copied
In the end, the archive attribute had been removed from everything in v:\ EXCEPT those few files which were copied (?) back to v:\.
Code:
v:\> attrib
___A______C____  V:\0.btm
___A____L______  V:\1.bat
___A____L______  V:\1.btm
___A____L______  V:\1.cmd
___A____L______  V:\2.bat
___A____L______  V:\2.btm
___A____L______  V:\2.cmd
______N________  V:\4.cmd
______N________  V:\4console.zip
______N________  V:\add.vb
<snip>
In e:\synctest, all the links became copies of the target ...
Code:
e:\synctest> d [012].*
2018-03-26  21:45          11,591  0.btm
2018-03-26  21:45          11,591  1.bat
2018-03-26  21:45          11,591  1.btm
2018-03-26  21:45          11,591  1.cmd
2018-03-26  21:45          11,591  2.bat
2018-03-26  21:45          11,591  2.btm
2018-03-26  21:45          11,591  2.cmd
... and all files in e:\synctest except these few have the archive attribute.
Code:
e:\synctest> attrib
___A___________  E:\synctest\0.btm
______N________  E:\synctest\1.bat
______N________  E:\synctest\1.btm
______N________  E:\synctest\1.cmd
______N________  E:\synctest\2.bat
______N________  E:\synctest\2.btm
______N________  E:\synctest\2.cmd
___A___________  E:\synctest\4.cmd
___A___________  E:\synctest\4console.zip
___A___________  E:\synctest\add.vb
<snip>
But back in v:\, those which were links are still links.
Code:
v:\> d [012].*
2018-03-26  21:45          11,591  0.btm
2018-03-26  13:10     <SYMLINK>    1.bat [V:\0.btm]
2018-03-25  19:54     <SYMLINK>    1.btm [V:\0.btm]
2018-03-26  13:04     <SYMLINK>    1.cmd [V:\0.btm]
2018-03-26  13:10     <SYMLINK>    2.bat [V:\1.btm]
2018-03-25  19:54     <SYMLINK>    2.btm [V:\1.btm]
2018-03-26  13:04     <SYMLINK>    2.cmd [V:\1.btm]
I don't understand it all, but a few things in v:\ wound up with the archive attribute still set.
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,599
46
Albuquerque, NM
prospero.unm.edu
#7
But then it continued a little. What's this all about?
Code:
SYNC: E:\synctest\ => V:\
E:\synctest\1.bat =>! V:\1.bat
E:\synctest\1.btm =>! V:\1.btm
E:\synctest\1.cmd =>! V:\1.cmd
E:\synctest\2.bat =>! V:\2.bat
E:\synctest\2.btm =>! V:\2.btm
E:\synctest\2.cmd =>! V:\2.cmd
     6 files copied
Different file systems, perhaps?
 
#12
The sync command seems now (in v23) even more "unstable".

I tried to sync some music files with some hidden files like "Folder.jpg" with attributes "-ahs" from one NTFS drive to another NTFS.

I used the syntax:
Code:
sync /M /X /S /H /Y d:\_Temp\Tests\ w:\Tests\
For ALL "-ahs" files the "a" attribute were NOT removed, EXCEPT for the one thumbs.db file.

Addtitionally some of the MP3 files still had the +a attribute too, others not ...
 

rps

Jul 6, 2008
300
4
#16
The files were all synchronized. The archive attribute wasn't removed for related source files.
I have been following this thread and decided to performed a small test showing SYNC cmd results in Win10 TCC V22 x64.

Code:
v22.00.42_$VER
TCC  22.00.42 x64   Windows 10 [Version 10.0.17134]
From V22 help file -- "/X Clear the archive attribute from the source file after a successful copy."

I believe the /x switch is in fact working as documented.

This is how the files looked before the sync cmd.

Code:
v22.00.42_$dir /[!*.ion] /a: /h /Nfv /t test03\ test04\

 Directory of  D:\BAT\test03\*

11/11/2017   5:00             270  ______N________  DummFNames.txt
 7/10/2018  22:50             948  RHSA___________  TEST123.txt
 7/10/2016  13:53              96  RHSA___________  Testlogfile.txt
               1,314 bytes in 3 files and 0 dirs    12,288 bytes allocated

 Directory of  D:\BAT\test04\*

 7/10/2018   2:26              82  _HSA___________  test12.txt
 1/08/2012  13:34             851  ___A___________  TEST123.TXT
 7/15/2016   1:49              15  ___A___________  testdatename-07-15.txt
11/12/2015   2:50             123  ___A___________  testDo.btm
               1,071 bytes in 4 files and 0 dirs    16,384 bytes allocated
Then I executed a sync command with all the appropriate switches.

Code:
v22.00.42_$sync /a: /H /K /M /S /X /Y test03\ test04\
SYNC: D:\BAT\test03\ => D:\BAT\test04\
D:\BAT\test03\TEST123.txt =>! D:\BAT\test04\TEST123.txt
D:\BAT\test03\Testlogfile.txt => D:\BAT\test04\Testlogfile.txt
     2 files copied
SYNC: D:\BAT\test04\ => D:\BAT\test03\
D:\BAT\test04\test12.txt => D:\BAT\test03\test12.txt
D:\BAT\test04\testdatename-07-15.txt => D:\BAT\test03\testdatename-07-15.txt
D:\BAT\test04\testDo.btm => D:\BAT\test03\testDo.btm
     3 files copied
After the sync with my added comments (<-):

Code:
v22.00.42_$dir /[!*.ion] /a: /h /Nfv /t test03\ test04\

 Directory of  D:\BAT\test03\*

11/11/2017   5:00             270  ______N________  DummFNames.txt <- Not copied with /M switch "Copy only those files with the archive attribute set".
 7/10/2018   2:26              82  _HSA___________  test12.txt <- Attributes are identical to the Source ..\test04
 7/10/2018  22:50             948  RHS____________  TEST123.txt <- Archive attribute cleared from this source.
 7/15/2016   1:49              15  ___A___________  testdatename-07-15.txt <- Attributes identical to the Source ..\test04
11/12/2015   2:50             123  ___A___________  testDo.btm <- Attributes identical to the Source ..\test04
 7/10/2016  13:53              96  RHS____________  Testlogfile.txt <- Archive attribute cleared from this source.
               1,534 bytes in 6 files and 0 dirs    24,576 bytes allocated

 Directory of  D:\BAT\test04\*

 7/10/2018   2:26              82  _HS____________  test12.txt <- Archive attribute cleared from this source.
 7/10/2018  22:50             948  RHSA___________  TEST123.TXT <- Attributes are identical to the Source ..\test03
 7/15/2016   1:49              15  ______N________  testdatename-07-15.txt <- Archive attribute cleared from this source.
11/12/2015   2:50             123  ______N________  testDo.btm <- Archive attribute cleared from this source.
 7/10/2016  13:53              96  RHSA___________  Testlogfile.txt <- Attributes identical to the Source ..\test03
               1,264 bytes in 5 files and 0 dirs    20,480 bytes allocated
As far as I can tell, the above attributes are set correctly per the docs. There is nothing special about files with or without HSA.
Only the source archive attribute is being cleared.
The destination file retains the sources Archive setting.

In your analysis, are you sure you are looking at the actual source file attribute to be cleared, not the destination files' which are being copied with the source files attributes?
Do you have a postable example where files are sync'd differently than above?
 
#17
I am sure about the source, yes! And no, I haven't an example, it's seems not always the same behaviour and also not really related to hidden/system files. The thing with hidden/system files was only an additionally weird thing in this case. It seems a generally problem with the clearing of the archive attribute for source files in some cases (here).

Interesting is also that Vince had also some problems with that ...

And last but not least it's also interesting that I NEVER had a problem with the xcopy /M command from Win OS.

However, I will keep an eye on this and would report it here, if I have more details
 
#18
Ok, here an example, which *I* can reprocude always it seems:

Here the source files as zip: https://www.alpengreis.ch/forums-external/SyncTest.zip

Both drives (x: and v:) are portable NTFS (note: portable is NOT the problem, also tested with two fix drives).

Here the source files with attribute +a is set (the destination folder is empty yet):

SyncSource.JPG

Then I made the following command in current build 24 of TCMD v23:

Code:
[X:\_Temp\SyncTest]sync /M /X /S /Y x:\_Temp\SyncTest\ v:\_Temp\SyncTest\
SYNC: X:\_Temp\SyncTest\ => V:\_Temp\SyncTest\
X:\_Temp\SyncTest\Test1.txt => V:\_Temp\SyncTest\Test1.txt
X:\_Temp\SyncTest\Test2.txt => V:\_Temp\SyncTest\Test2.txt
X:\_Temp\SyncTest\Test3.txt => V:\_Temp\SyncTest\Test3.txt
X:\_Temp\SyncTest\Test4.txt => V:\_Temp\SyncTest\Test4.txt
X:\_Temp\SyncTest\Test5.txt => V:\_Temp\SyncTest\Test5.txt
X:\_Temp\SyncTest\Test6.txt => V:\_Temp\SyncTest\Test6.txt
X:\_Temp\SyncTest\Test7.txt => V:\_Temp\SyncTest\Test7.txt
X:\_Temp\SyncTest\Test8.txt => V:\_Temp\SyncTest\Test8.txt
X:\_Temp\SyncTest\Test9.txt => V:\_Temp\SyncTest\Test9.txt
     9 Dateien kopiert
SYNC: V:\_Temp\SyncTest\ => X:\_Temp\SyncTest\
     0 Dateien kopiert

Here the result:

SyncResult.JPG

As you can see the source file Test2.txt has still the archive attribut set.

HERE, I can reproduce it always it seems ...


And now the same with XCOPY in Win Console:

Code:
X:\>xcopy /M /S /Y "x:\_Temp\SyncTest\*.*" "v:\_Temp\SyncTest\"
X:\_Temp\SyncTest\Test1.txt
X:\_Temp\SyncTest\Test2.txt
X:\_Temp\SyncTest\Test3.txt
X:\_Temp\SyncTest\Test4.txt
X:\_Temp\SyncTest\Test5.txt
X:\_Temp\SyncTest\Test6.txt
X:\_Temp\SyncTest\Test7.txt
X:\_Temp\SyncTest\Test8.txt
X:\_Temp\SyncTest\Test9.txt
9 Datei(en) kopiert
Sync-Result_xcopy.JPG

No problems with xcopy, never had one.


PS: I tried also the reverse way from x: to v: with same result ...
PPS: Tested also without AV-Scanner ...
 
Last edited:

rconn

Administrator
Staff member
May 14, 2008
10,551
97
#21
I hve new "detail", which seems very important in this case:

If I add the /G parameter, it works!
The only thing the /G option will affect in this case is the speed of the copy (it will slow it down slightly). Which makes me wonder if you have a timing issue on your system -- it's not unknown for Windows APIs to fail if they're called too quickly in succession.
 

rps

Jul 6, 2008
300
4
#22
The only thing the /G option will affect in this case is the speed of the copy (it will slow it down slightly). Which makes me wonder if you have a timing issue on your system -- it's not unknown for Windows APIs to fail if they're called too quickly in succession.
Rex; I guess someone will be suggesting a "slower" parameter. :eek:
Don't be looking for that suggestion in the foreseeable future. :hilarious:
 

rps

Jul 6, 2008
300
4
#23
Today at 12:36 PM
#18

Ok, here an example, which *I* can reprocude always it seems:

Here the source files as zip: https://www.alpengreis.ch/forums-external/SyncTest.zip

Both drives (x: and v:) are portable NTFS (note: portable is NOT the problem, also tested with two fix drives).

Then I made the following command in current build 24 of TCMD v23:

Code:
[X:\_Temp\SyncTest]sync /M /X /S /Y x:\_Temp\SyncTest\ v:\_Temp\SyncTest\
SYNC: X:\_Temp\SyncTest\ => V:\_Temp\SyncTest\
X:\_Temp\SyncTest\Test1.txt => V:\_Temp\SyncTest\Test1.txt
..................................
9 Dateien kopiert
SYNC: V:\_Temp\SyncTest\ => X:\_Temp\SyncTest\
0 Dateien kopiert
Here the result:





As you can see the source file Test2.txt has still the archive attribute set.

HERE, I can reproduce it always it seems ...
Thanks for the example. I unfortunately can't reproduce the outlier (Test2 maintaining the A attribute) no matter what I have tried.

I posted a small example, but executed the same script with many more files on both sides of the Sync and everything worked without fail both in v22 and v23.

In your case; 1 failure in 9 is a pretty big error rate if this carries through to directories with several 100 files each.
Sounds like you found a solution with /G option. Slower but works without error. :happy: