Bug? A file was concurrently modified!

[theChaosCoder]

I made a test run with wimlib-1.12.0-windows-x86_64 (Win10 Pro 15063) and got this error:

Code: Select all

[ERROR] A file was concurrently modified!9%) done
        Path: "\??\GLOBALROOT\Device\HarddiskVolumeShadowCopy11\ProgramData\Acronis\BackupAndRecovery\MMSData\DML\F4CEEE47-042C-4828-95A0-DE44EC267A28.db3-shm"
        Expected SHA-1: e50176b8a65dfb56215357e8435ffd4a6ee15f11
        Actual SHA-1: 03ec400bb3c4b807078fbd9444eb2543ed72bed8

ERROR: Exiting with error code 88:
       A file being added to a WIM image was concurrently modified.

With this command:

Code: Select all

.\wimlib-imagex.exe capture c:\ Win2.wim WIn2 blabla --update-of=Win1.wim:-1 --config=EXCLUDE_shit.txt --compress=LZX:20 --snapshot

I think this shouldn't happen with a --snapshot parameter!?

Command for previous Win1.wim:

Code: Select all

.\wimlib-imagex.exe capture c:\ Win1.wim WIn1 blabla --compress=LZX:20 --snapshot

[ExclusionList]
\Users\bla\Pictures\Lightroom\Lightroom Catalog Previews.lrdata\*
\Lightroom Catalog Previews.lrdata\*




//EDIT
--delta-from=Win1.wim instead to update-of seems to work just fine. And the wim file is much smaller.

[synchronicity]

Most likely the problem is related to the use of --update-of, and with Windows not keeping file modification times up to date, similar to this previously reported issue: viewtopic.php?f=1&t=280. (Edit: also this issue: viewtopic.php?f=1&t=270.) If a file has the same size and last modification time as in the image specified by --update-of, but yet has different contents when actually read, you will see the "concurrent modification" error.

It would theoretically be possible to change wimlib to override the hash from the --update-of image with the actual hash computed while reading the file. That would make it stop reporting a "concurrent modification" error. But that doesn't really solve the problem because with --update-of, many files are deduplicated without being read --- which after all is the whole point of the option. So the new image would show the old contents for some files rather than the current contents, which can be very problematic.

Unfortunately I'm not sure what can be done about this, other than disabling support for --update-of on Windows...

Of course, as a workaround it should work fine if you just remove --update-of from the command line.

[theChaosCoder]

Does --delta-from not depend on the mod timestamp like update-of?

And I still haven't figured out what the real difference between delta-of und update-of is, except that update-of needs an IMAGE and Dealta just the wim file...

[synchronicity]

They do different things. Briefly, --update-of is a hint which allows the checksums for unmodified files to be copied from the specified image, so that duplicate files don't need to be read. Whereas --delta-from creates a "delta WIM" which contains only file data that isn't already included in the specified WIM file. You can use both options at the same time, or just one, or neither. Please read the documentation for more details.

[theChaosCoder]

Thank you for the explanation.