-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shadow file names #9
Comments
The current shadow file naming behavior you describe, while understandably unexpected, is nonetheless correct. Shadow file naming was corrected back on July 19, 2015 by commit eb05741 to match the published documentation, causing shadow file names to unexpectedly change for users using shadow file names with more than one period in them. Users whose shadow file names did not contain any extra periods were not affected. Unfortunately you happen to be one of the users that was affected. For that I apologize. The rule regarding the placement of the shadow file number in a given shadow file name has always been to place it immediately prior to the last period of the name (i.e. immediately before the period preceding the filename extension (or at the last character of the filename if there is no extension)). Earlier versions of Hercules (including the 3.x spinhawk series) contained a day one bug that was erroneously placing the shadow file number immediately before the first period in the filename. This was fixed in Hyperion back on July 19, 2015 by commit eb05741 to match the published documentation, which was the behavior users were told to expect. The version you were previously using (4.00.0.8143) did not yet contain this fix. The current version of Hyperion however does contain this fix, which is why you are now experiencing the behavior you are experiencing. The behavior you are now experiencing is actually the correct behavior, whereas the behavior you were experiencing with your older version of Hyperion was actually incorrect behavior that did not match the published documentation. This was not a documentation error. It was an implementation error. The documentation was actually correct. The code that tried to implement it however was not correct (but was fixed as I said back on July 19, 2015). I do apologize for whatever inconvenience this issue may have caused you, but I'm afraid there is nothing to be fixed. The current version of Hyperion is actually working as designed. Nevertheless I have now made some additional changes to the documentation to provide a more detailed explanation of how shadow file naming actually works along with some working examples: My hope is that it might help prevent others from tripping over this unexpected change in behavior. Thank you for reporting it. |
Thanks, that's fine, I can update my file naming convention. I did not notice until recently when I spotted some orphaned shadow files but did not really cause too much problem as I merge frequently. |
. New test #8: Write Data, erase reminder of track . New test #9: Verify test #8 erasure (try reading record on erased track) Note: This update required recreating the "3390.cckd64" test dasd to actually have data on track 0, and adding shadow file support to the test script to ensure the actual base dasd image is never actually modified since it is a part of the repository. (We don't want our verification tests to actually modify any repository files!)
Hi, I recently upgraded to 4.0.0.8745 and the shadow file names seem to have changed.
I use:
and in prior versions (4.00.0.8143) the shadow file were named
DLB001_Shadow_1.3390-9.comp-z
With the current version of Hyperion I am now getting shadow files named
DLB001_Shadow_0.3390-1.comp-z
.The shadow number is going after the
-
(dash) instead of the_
(underscore).The text was updated successfully, but these errors were encountered: