Why is it that when I do a "Mirror Task" from the VSE GUI, it gives a repository (about 700 MB) with mixed-case file names, but the common updater site has them all lower case? Making the mixed-case Mirror Task download available on the Intranet via http works just fine - workstations (Win10 VSE8.8 P13) pointing to it will update. But they don't recognize the lowercase version from Common Updater. I ran Beyond Compare to verify that both downloads had identical content, just different file name cases. The common updater site I used was : http://update.nai.com/products/commonupdater
Solved! Go to Solution.
Hi @RAL
Yes. Replica.log has been verified at each level. Just one another question, is it creating any issue at the client end during the DAT update? Once the Mirror task is complete, DAT update for the clients should work fine.
Hi @RAL
Thank you for your post. Can you please share a screenshot of what Files you are getting and what you are expecting to get?
From the Mirror, there's a folder "Current" and files such as "DATRep.zip" and "DATRepHC.zip" while on the download site at http://update.nai.com/products/commonupdater the same files are all lowercase: the folder "current" and files "datrep.zip" and "datrephc.zip"
Where is the "MIrror Task" getting its data?
Most likely, the replication function of the mirror task is simply obeying the content contained within some control file (eg, replica.log) which contains Mixed-Case names, rather than all lower-case file names on the actual site.
For example, see "DATRep.zip" and other Mixed-Case file names contained within: http://update.nai.com/products/commonupdater/replica.log
Otherwise, there may be a compressed .z, .zip, or .cab file that gets downloaded/replicated, then expanded, which contains the Mixed-Case file names.
Hope this helps.
Yes, the Replica.log file does indicate the original mixed-case names at each level.
McAfee - could it be that the Mirror Task uses the Replica.log file at each level to set the correct file names and verify their hashes? If so, that would answer the question.
Hi @RAL
Yes. Replica.log has been verified at each level. Just one another question, is it creating any issue at the client end during the DAT update? Once the Mirror task is complete, DAT update for the clients should work fine.
OK, so I take this as confirmation that the purpose of the Replica.log at each level is to provide hashes and "true" file name information, and that it's set up this way by design for file integrity.
The regular "mirror task" from within VSE produces a mixed-case repository to which clients can point via http.
What's interesting is that the "lowercase" wget archive works "as is" when the client points to it as a Local Path, but the "true" mixed-case file names are needed when the client points to it via http: on an intranet web site.
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA