You'd need to show us your fc and fci scripts/aliases to allow further investigation, i.e. are they doing anything special?

Similar problems have already been reported:

• Appreciating the "different on disk compared to the repository" error
• Bug with ADDED_BY_MERGE files?

You may find explanations and solutions in the linked posts, i.e. check the mtime-changes option.

Please report back if your problem isn't explained and resolved, or if your fc and fci commands are doing something fancy.

TL;DR If you're really quick at changing your files so that their time stamps don't change, you need to disable the mtime-changes setting, or use the --hash option for the ci command.

Note this problem can also happen if the file time stamps are overwritten (i.e. reset to an older date) when extracting a zip archive into the check-out directory.

alias f='fossil '
alias fa='fossil add '
alias fc='fossil changes '
alias fci='fossil ci '
alias fd='fossil diff '
alias fdb='fossil diff --by '
alias fdk='fossil diff --tk '
alias fe='fossil extras '
alias fh='fossil help '
alias fs='fossil status '

Hm, nothing too fancy.

Changing this alias should fix your problem:

alias fci='fossil ci --hash '

But maybe it's better to specify the --hash option only when needed, and make sure you understand why the time stamp-based change detection failed in your scenario:

• Any script tampering with the files and their time stamps? Fast "change and commit in a series" scripts can cause the reported error if the modifications happen fast enough to hit the same second.

• Restored a zip backup archive of the source tree with older time stamps?

• Copied over the source tree from FAT (USB drive) to NTFS? The former has lower file time stamp granularity, hence copy operations may result in changed/unexpected time stamps?

You can also use the mtime-changes to avoid this problem in the future, but this will slow down Fossil when working with large source trees, as all files are constantly re-hashed to detect changes.

Nothing changed my checkout tree. I turned off mtime-changes and the error disappeared. My tree is not that large so I can live with re-hash to detect changes.

I would love to know why I suddenly got this error. And the previous one https://fossil-scm.org/forum/forumpost/160515715a. Weird.

Does the current problem also appear in a Cygwin environment? Maybe somehow related to Cygwin's emulation and caching of file metadata, i.e. Fossil still sees the old file time even though the file contents have already changed.

I'm at loss ... but glad you found a solution.