On Windows, sync_replica does not reliably clean old journals.
=== BEGIN LOG ===
Observed on a customer replica's sync.log:
Start Sync Replica
Wed 02/22/2023
04:00 AM
xcopy /D /I \\P4DServer-04\F$\p4\1\checkpoints\*.* c:\p4\1\checkpoints\*.*
\\P4DServer-04\F$\p4\1\checkpoints\p4_1.ckp.936.gz
\\P4DServer-04\F$\p4\1\checkpoints\p4_1.ckp.936.gz.md5
2 File(s) copied
Determining current journal counter with 'p4 counter journal'.
Journal counter 936 found.
ATTRIB -r c:\p4\1\checkpoints\*.925.* <-- The *.925.* does not
del c:\p4\1\checkpoints\*.925.* catch the jnl file, so
c:\p4\1\checkpoints\p4_1.jnl.925 the ATTRIB -r is not done.
Access is denied. <-- The "Access is denied." is
del c:\p4\1\offline_db\db.* because the ATTRIB is not done.
c:\p4\1\bin\p4d.exe -r c:\p4\1\offline_db -jr -z c:\p4\1\checkpoints\p4_1.ckp.936.gz
Perforce db files in 'c:\p4\1\offline_db' will be created if missing...
Recovering from c:\p4\1\checkpoints\p4_1.ckp.936.gz...
End Sync Replica
Wed 02/22/2023
04:04 AM
=== END LOG ===
A possible solution is to change the 'DEL' command to 'DEL /F/Q', making the 'ATTRIB -R'
unnecessary.
Here are sample manual commands and outputs illustrating first change to the
wildcard handling to make the ATTRIB apply to the journal, and then trying 'DEL'
with the '/F/Q' options (thus no need for 'ATTRIB').
C:\p4\1\checkpoints>ATTRIB p4_1.jnl.225
A R C:\p4\1\checkpoints\p4_1.jnl.225
C:\p4\1\checkpoints>ATTRIB *.226.*
A R C:\p4\1\checkpoints\p4_1.ckp.226.gz
A R C:\p4\1\checkpoints\p4_1.ckp.226.gz.md5
C:\p4\1\checkpoints>ATTRIB *.jnl.226
A R C:\p4\1\checkpoints\p4_1.jnl.226
C:\p4\1\checkpoints>ATTRIB -r *.226.*
C:\p4\1\checkpoints>ATTRIB -r *.jnl.226
C:\p4\1\checkpoints>ATTRIB *.226.*
A C:\p4\1\checkpoints\p4_1.ckp.226.gz
A C:\p4\1\checkpoints\p4_1.ckp.226.gz.md5
C:\p4\1\checkpoints>ATTRIB *.jnl.226
A C:\p4\1\checkpoints\p4_1.jnl.226