Appreciating the "different on disk compared to the repository" error
(1) By Stephen Weigand (weigand) on 2021-11-04 05:20:24 [link] [source]
Hi to All,
I'm sharing some "solved confusion" in case it helps other Fossil users who search this forum with a similar error. And I have a few questions. (I am using Fossil version 2.17 on Windows via the Scoop command line installer.)
Encountering the "different on disk compared to the repository" error
I periodically download a zip file consisting of a collection of CSV files, unzip it, and check in the changes. I did this and got this error:
fossil commit --no-warnings -m "Check-in of unzipped download from today"
Autosync: ssh://weigand@...
Password:
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, wire bytes sent: 464 received: 275...
New_Version: 7b53824bb20526c57f8c2cfc5c44e496e6bd42d2901b23052cfc095f7914e68e
ERROR: [ABCD.csv] is different on disk compared to the repository
NOTICE: Repository version of [ABCD.csv] stored in [file-a698d9b026622554]
working checkout does not match what would have ended up in the repository: 7aeb871f13bf979ddda8f63c7298e464 versus 9125ff5e25073c78196cbd828f4fd9ae
Reason for this error
Unfortunately, all the files unzip with a timestamp of 1/1/2000 12:00 AM
and as luck would have it, the file ABCD.csv
had a few edits such as date changes but no change to the number of characters. So I think fossil commit
didn't expect ABCD.csv
to have changed.
But thanks to this answer I learned:
Prior to committing the transaction that adds the new artifacts, Fossil double-checks to ensure that the new check-in exactly matches what is currently on disk...
And this kind of discrepancy in ABCD.csv
...causes fossil to abort its check-in (rolling back the transaction) and issuing the error.
What a great safety net.
Solution
The solution I used was to add the --hash
option to fossil commit
.
Questions
First, I was a confused that the following command didn't give any output. (Not a Windows oddity, right?)
PS> fossil diff .\ABCD.csv
Second, are there commands that would have helped me understand what was going on with ABCD.csv
or what would others have done next?
Thanks to all who contribute to Fossil and answer questions on the forum.
Sincerely,
Stephen
(2) By Florian Balmer (florian.balmer) on 2021-11-04 07:43:28 in reply to 1 [source]
I haven't checked all the details, but isn't this the problem solved by this commit? See the forum thread linked by the check-in comment for more information.
(3) By Florian Balmer (florian.balmer) on 2021-11-04 11:53:06 in reply to 1 [link] [source]
Please disregard my previous post -- your case is different from that mentioned above.
If the mtime-changes
setting is enabled, Fossil won't detect modified
files with preserved file sizes and mtimes.
As you already found out, the --hash
option of fossil commit
comes to
the rescue. The --hash
option is also available for fossil changes
, but
not for fossil diff
.
However, as soon as fossil changes --hash
has detected and (recorded
internally) the changes, fossil diff
is able to see them.
Or, if this is inconvenient, disable the mtime-changes
setting for your
repository, with the consequence that any operations involving change detection
may run slower.
Also note there's other factors to influence (i.e. preserve) file mtimes on Windows.
(4) By Warren Young (wyoung) on 2021-11-04 12:30:45 in reply to 3 [link] [source]
If the
mtime-changes
setting is enabled...
...which it is by default, so given the OP's report that mtimes aren't expected to change from one version to the next, this is definitely something that should be enabled for this repo.
(5) By Stephen Weigand (weigand) on 2021-11-04 14:02:25 in reply to 4 [link] [source]
Thank you very much Florian and Warren for the additional information. I have done this to disable it for this repo:
fossil settings mtime-changes 0
Fossil is good!