Skip to content
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

Handling intentional changes to files #134

Open
OlliTee opened this issue Feb 6, 2023 · 1 comment
Open

Handling intentional changes to files #134

OlliTee opened this issue Feb 6, 2023 · 1 comment

Comments

@OlliTee
Copy link

OlliTee commented Feb 6, 2023

To cover my bases, I’d like to present my particular use case that is not reflected in the examples/scenarios.
Imagine a source folder containing an ascmhl file and a tool that will transcode only a particular type of file and copy everything else. The file name of the transcoded output is changed to identify files with the new codec.

For all transcoded files, a verification with ascmhl tool would result in an Error: Files referenced in the ASC MHL history are missing, and a new original hash for the newly created output.
The verbose output of ascmhl create -h xxh64 -v /Volumes/PRO-BLADE1/HDE_HDET_asc-verify/A_0001_12NR
would be:

Creating new generation for folder at path: /Volumes/PRO-BLADE1/HDE_HDET_asc-verify/A_0001_12NR ...
  verified                      A_0001_12NR_AVID.ale  xxh64: OK
  verified                      A_0001_12NR_BIN.bin  xxh64: OK
  created original hash for     A_0001C001_230202_052359_h12NR.mxf  xxh64: 831634f910e235ac
  created original hash for     A_0001C002_230202_052419_h12NR.mxf  xxh64: d07e0727d0934ba0
  created original hash for     A_0001C003_230202_052434_h12NR.mxf  xxh64: d3a52efeb7f20374
  created original hash for     A_0001C004_230202_052442_h12NR.mxf  xxh64: 25240d1fce0973a5
  created original hash for     A_0001C005_230202_052515_h12NR.mxf  xxh64: a04dfa3627d7c388
  created original hash for     A_0001C006_230202_052533_h12NR.mxf  xxh64: 0ed10f15dc9bfed7
  created original hash for     A_0001C007_230202_052647_h12NR.mxf  xxh64: 36d57baffa34b7a8
  created original hash for     A_0001C008_230202_052708_h12NR.mxf  xxh64: b7ee8d900446b429
  calculated root hash  xxh64: 6c1753e87fbd0b4e (content), b86f699d4b3d60b2 (structure)
Created new generation ascmhl/230207_A_0001_12NR_2023-02-06_173319.mhl
ERROR: 8 missing file(s):
  A_0001C001_230202_052359_a12NR.mxf
  A_0001C008_230202_052708_a12NR.mxf
  A_0001C004_230202_052442_a12NR.mxf
  A_0001C002_230202_052419_a12NR.mxf
  A_0001C007_230202_052647_a12NR.mxf
  A_0001C003_230202_052434_a12NR.mxf
  A_0001C006_230202_052533_a12NR.mxf
  A_0001C005_230202_052708_a12NR.mxf

And the output ascmhl would show
<xxh64 action="verified"… for the two verified files and <xxh64 action="original"… for the newly created files.

Does this implementation look alright for you or should I handle it differently?

@akda5id
Copy link

akda5id commented Apr 6, 2023

And, there needs to be a way (added to the spec) to "accept" changes to the MHL. A flag for the create command that creates a new generation without any errors for missing files or changed hashes. Ideally with some info logging in the MHL that notes what was changed, but future generations wouldn't include.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants