PCAssistSoftware
commented
2 years ago Response from @RFBomb
This should only Affect ListOnly operations, as OnCopyProgressChanged lets PE know if a file has started/finished copying regardless of what it identified as for XO/XN/Same/etc.
I've provided the base logic for it, if you or someone else wants to expand on that pattern to include all the possible tags (which I think is overkill unless we also include the robocopy language files to identify the tags), the. That's fine. But expanding past what I've currently provided for that is something I'm not interested in doing, since it will primarily affect only ListOnly operations.
Plus, it may already be handled:
if (currentFile.FileClass.Equals(Config.LogParsing_NewerFile, StringComparison.CurrentCultureIgnoreCase))
{
if (command.SelectionOptions.ExcludeNewer)
PerformByteCalc(currentFile, WhereToAdd.Skipped);
else
PerformByteCalc(currentFile, WhereToAdd.Copied);Response from @PCAssistSoftware
From the tests I have done it doesn't just affect ListOnly - see figures below comparing with /IS and without /IS - results are fine, just progress estimator which is wrong
Also a more immediate issue when using /IS for some reason in the OnCopyProgressChanged event e.CurrentFile.Name is nothing despite file obviously being copied as shows CurrentFileProgress
Response from @RFBomb
Ok then update PE AddFile method to make it work.
Response from @PCAssistSoftware
Okay will look this week and see what I can do, may as well try and cover all bases, no point offering the switches in GUI if it then breaks parts the estimator.
Any comment on second issue in last post as that seems a more serious problem potentially?
Response from @RFBomb
That's because in PE it's being set to null because the check for 'same' doesn't follow the same pattern as XN and XO. If you look at the file, the issue should be pretty easy to see and update to a similar pattern
(Fixing one should fix both - same root cause)
Response from @PCAssistSoftware
That's because in PE it's being set to null because the check for 'same' doesn't follow the same pattern as XN and XO. If you look at the file, the issue should be pretty easy to see and update to a similar pattern
Okay will spend some time on it this week, may come back for some advice if I get stuck, but more than happy to have a go
(Fixing one should fix both - same root cause)
That's what I thought - good
RFBomb
Initially discussed here - https://github.com/tjscience/RoboSharp/pull/147#issuecomment-1030865157
Key points of discussion copied below - will start working on PR this week.
I think changes / improvements may be needed to log parsing for estimator as just been reading some RoboCopy documentation and doing some tests with switches such as /IS (include same)
Log shows same (all in lower case) normally, but if using /IS then the S is capitalized (Same) - we only handle it correctly if lowercase (according to what I see in RoboSharpConfiguration.cs) - so this affects values for copied / skipped.
Uppercase S means copied (e.g. using /IS), lowercase s means skipped (default behaviour)
N.B. same logic possibly applies to other switches such as /XO (exclude older) and /XN (exclude newer) as we only handle Newer / Older and not newer / older.Still looking at /IT (include tweaked), /XC (exclude changed) as these can return Tweaked / tweaked or Changed / changed but not sure how (or if) we handle these currently - but certainly dependent on switches and upper/lower case first letter would make difference to results being correctly counted as copied or skipped.
Really handy reference to all the tags here - https://theether.net/download/Microsoft/Utilities/robocopy.pdf - is for older version of RoboCopy but just tested and all still relevant to current version - see page 30.
Also shows lots of tags I never even knew about which again we don't handle but could affect results shown e.g. large, small, too new, too old, attrib when using switches such as /MIN, /MAX, /MINAGE, /MAXAGE, /XA