Hi....
I'm trying to use the --update-of option in wimcapture (linux version). I admit I'm not sure if I'm using it correctly but here is what I did:
1. Created initial WIM file of a hard drive (/dev/sda1):
wimcapture /dev/sda1 win7.wim Windows7WIM
2. Booted back into the hard drive, made some changes, added a few applications (eg: Office 2016)
3. Booted into Linux again and did the following:
wimcapture /dev/sda1 win7u2.wim Windows7WIMU2 --update-of=win7.wim:1
When I run this last command, I get the following output:
[ERROR] File data was concurrently modified!one
Location ID: 5
Expected SHA-1: cf88d7d5a9ae87e5c7205418e71c57d3b04008ae
Actual SHA-1: cef8ec4aed24da2ae72c96cc27a99f24d855091b
ERROR: Exiting with error code 88:
A file being added to a WIM image was concurrently modified.
Like I said, maybe I'm using the commands incorrectly, but what does this error mean? Is there something I can do about it?
Thanks in advance.
Chris.
File concurrently modified code 88
-
synchronicity
- Site Admin
- Posts: 474
- Joined: Sun Aug 02, 2015 10:31 pm
Re: File concurrently modified code 88
Yes, you used the commands correctly, although --update-of is more effective
when appending an image to an existing WIM archive, as opposed to creating a new
one.
The error message is a little misleading in this case. It was originally
intended to appear if any files being archived were being modified at the same
time. But in this situation, since you are using --update-of and creating a new
WIM archive rather than appending to an existing one, it likely has a different
cause: a file was modified between the time the two images were created, but
neither the last modification timestamp nor the size of the file was changed.
Hence, wimlib found that the actual checksum did not match the expected checksum
after the file's data was read.
Unfortunately, there may not be anything I can do about last modification
timestamps not being updated. It is the responsibility of the filesystem ---
Windows' NTFS implementation in this case --- to ensure they are updated. wimlib
also uses the maximum possible precision (100 nanoseconds) when examining the
timestamps, so it there was any change at all it would be detected.
A possibility is that the Windows system was not shut down cleanly and that caused
the timestamps to not get updated.
when appending an image to an existing WIM archive, as opposed to creating a new
one.
The error message is a little misleading in this case. It was originally
intended to appear if any files being archived were being modified at the same
time. But in this situation, since you are using --update-of and creating a new
WIM archive rather than appending to an existing one, it likely has a different
cause: a file was modified between the time the two images were created, but
neither the last modification timestamp nor the size of the file was changed.
Hence, wimlib found that the actual checksum did not match the expected checksum
after the file's data was read.
Unfortunately, there may not be anything I can do about last modification
timestamps not being updated. It is the responsibility of the filesystem ---
Windows' NTFS implementation in this case --- to ensure they are updated. wimlib
also uses the maximum possible precision (100 nanoseconds) when examining the
timestamps, so it there was any change at all it would be detected.
A possibility is that the Windows system was not shut down cleanly and that caused
the timestamps to not get updated.