Fossil User Forum

Appreciating the ”different on disk compared to the repository” error
Login

Appreciating the ”different on disk compared to the repository” error

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!