ERROR: [...] is different on disk compared to the repository

(1.1) Originally by refaqtor (refaQtor) with edits by Richard Hipp (drh) on 2019-06-14 17:04:54 from 1.0 [link] [source]

OK, OK, before anyone mentions it, I know fossil wasn't created to work in this environment, but...

how does one deal with this?
how does it get in this state?
can it be backed out without losing the current new data on disk?
or even with losing it?

ERROR: [uptime.txt] is different on disk compared to the repository NOTICE: Repository version of [uptime.txt] stored in [file-9e7291a230baee54] working checkout does not match what would have ended up in the repository: 5ca0c82dea30162aca051b4e01a13283 versus 3567d989b3712f66f36acf7e95db45f6

even pulling out all the stops, and putting into a new branch, doesn't do it

fossil commit --branch justdoit --allow-empty --no-prompt --allow-fork --allow-older --allow-conflict --no-warnings --force -m "just capture this data the way it is"

I've tried to store it --private. I stashed it, which seemed to work by REVERTing all the files, resulting in "fossil changes" returning nothing. But, the same commit just after updating a line in one file, returns the same ERROR.

This is on an unattended embedded system, and, likely, the power failed midway through something.

(2) By Richard Hipp (drh) on 2019-06-14 17:08:02 in reply to 1.1 [link] [source]

ERROR: [uptime.txt] is different on disk compared to the repository NOTICE: Repository version of [uptime.txt] stored in [file-9e7291a230baee54]

Can you do a comparison between you "uptime.txt" file and your "file-9e7291a230baee54" file and show us what is different between the two? You might need to do a binary comparison.

(3) By refaqtor (refaQtor) on 2019-06-14 17:46:33 in reply to 2 [link] [source]

$ diff uptime.txt file-9e7291a230bae1c1

<  01:22:35 up 2 min,  0 users,  load average: 2.05, 1.86, 0.78
>  01:22:35 up 2 min,  0 users,  load average: 2.29, 1.95, 0.81

(4) By refaqtor (refaQtor) on 2019-06-14 18:04:22 in reply to 3 [link] [source]

that was just plain "diff"

I guess I don't fully understand, if you meant "fossil --diff-bin .."

Thank you for your attention. Most appreciated! I respect Fossil (and SQLite) for their respect for data integrity, though I'm abusing it here.

I'm guessing you recognize where all the "file..." files came from. Some earlier fossil abuse of forcing commits, I assume.

(5) By Richard Hipp (drh) on 2019-06-14 18:07:44 in reply to 3 [source]

My guess at what is happening is this:

You have some background process that is periodically updating the "uptime.txt" file, perhaps once per second.
You run "fossil commit"
Fossil checks all of your managed files and sees that "update.txt" has changed, as well as possibly some other files.
Fossil gathers the changed files together and generates a new collections of check-in artifacts and adds those to the repository.
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. However, in the mean time, your background process from step (1) has modified the "uptime.txt" file such that the two files no longer agree. This causes fossil to abort its check-in (rolling back the transaction) and issuing the error.

(6) By Richard Hipp (drh) on 2019-06-14 18:13:12 in reply to 5 [link] [source]

Looking at the code, it appears that you can disable step 5 above, and thus possibly get your commit to run to completion, by doing a one-time setting change:

fossil setting repo-cksum off

(7) By refaqtor (refaQtor) on 2019-06-14 18:35:45 in reply to 6 [link] [source]

Thanks for all your help! I don't mean to be committing that frequently. I'll check to see that I'm not, in real time, committing that often. And, waiting until after I've gotten the clock set to actual time (via GPS data) before making any new commits might help. I was really impressed how well Fossil was handling the instances where the clock gyrated wildly over several commits (--allow-forks).

Anyway, super insight. Thanks! I'll try the one-time setting change to recover this, and try to avoid it in the future.

(8) By Stephan Beal (stephan) on 2019-06-14 18:39:14 in reply to 7 [link] [source]

Another option which would not require disabling that "final level" of integrity check is, instead of committing a file which is potentially being updated by an external process, creating a copy of that file and committing the copy. In effect:

cp uptime.txt uptime2.txt
fossil ci -m blah uptime2.txt

(9) By refaqtor (refaQtor) on 2019-06-14 19:00:39 in reply to 8 [link] [source]

Thank you. I'll consider that an option.

(10) By refaqtor (refaQtor) on 2019-06-15 14:49:29 in reply to 8 [link] [source]

d'oH! actually, this is the exact strategy that I used on a whole folder with good success about 5 years ago! Thank you for jogging my memory.

I kept a hidden app folder that Fossil worked in. I'd copy all the user project files to this folder and spawn a process for Fossil, while the user continued working on their own files.