Remove calibrateMtimeChangeDelay, it's irrelevant for modern file systems - #11496
Merged
Conversation
Bodigrim
force-pushed
the
no-calibrateMtimeChangeDelay
branch
3 times, most recently
from
February 18, 2026 23:47
8157360 to
7d5a397
Compare
Collaborator
|
I find that somewhat amusing given that it was 2 seconds on FAT. |
geekosaur
approved these changes
Feb 18, 2026
geekosaur
left a comment
geekosaur
left a comment
Collaborator
There was a problem hiding this comment.
I do wonder if network file systems were ever relevant for this, though.
Bodigrim
marked this pull request as ready for review
February 19, 2026 02:32
Collaborator
Author
|
Could someone else provide a second review please? |
Bodigrim
force-pushed
the
no-calibrateMtimeChangeDelay
branch
from
February 23, 2026 21:26
7d5a397 to
cd15477
Compare
ulysses4ever
approved these changes
Feb 24, 2026
Collaborator
FAT is still relevant though? |
Collaborator
|
For development / operation, or only for data transfer? Thumb drives are still slow enough that running from one isn't exactly recommended, and it's been a long time since computers shipped with preinstalled FAT filesystems. |
Collaborator
Author
|
…tems There was time long ago when different file systems clocked file modification time with significant granularity and `calibrateMtimeChangeDelay` had its purpose. But this time is long gone and for the past decade all modern file systems (ext4, ntfs, apfs) have submicrosecond granularity. `calibrateMtimeChangeDelay` was used only in test suites and returned values between 10ms and 1s. We can safely default it to 10ms, because all modern file systems have finer precision. It's a low risk change: after all it's only for tests, not for Cabal itself. (Interestingly, it seems `calibrateMtimeChangeDelay` was never really fit for purpose: its output is capped with 1s, while granularity of FAT filesystem is 2s) As an extra precaution, modification time delay remains configurable in the test suite via `--mtime-change-delay`.
Bodigrim
force-pushed
the
no-calibrateMtimeChangeDelay
branch
from
February 24, 2026 20:35
cd15477 to
ba7cd60
Compare
Collaborator
|
All right, thank you for the answers |
Bodigrim
added
merge me
mergify
Bot
added
ready and waiting
Contributor
Merge Queue StatusRule:
This pull request spent 1 hour 40 minutes 57 seconds in the queue, including 1 hour 30 minutes 17 seconds running CI. Required conditions to merge
ReasonThe merge conditions cannot be satisfied due to failing checks Failing checks: HintYou may have to fix your CI before adding the pull request to the queue again. |
86 tasks
Collaborator
|
I'll requeue it later. The latest weird build failure is Windows (usually 9.2.8) |
Collaborator
|
@Mergifyio queue |
Contributor
Merge Queue StatusRule:
This pull request spent 2 hours 17 minutes 36 seconds in the queue, including 2 hours 6 minutes 33 seconds running CI. Required conditions to merge
|
86 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There was time long ago when different file systems clocked file modification time with significant granularity and
calibrateMtimeChangeDelayhad its purpose. But this time is long gone and for the past decade all modern file systems (ext4, ntfs, apfs) have submicrosecond granularity.calibrateMtimeChangeDelaywas used only in test suites and returned values between 10ms and 1s. We can safely default it to 10ms, because all modern file systems have finer precision. It's a low risk change: after all it's only for tests, not for Cabal itself.As an extra precaution, modification time delay remains configurable in the test suite via
--mtime-change-delay.Template Α: This PR modifies behaviour or interface
Include the following checklist in your PR:
significance: significantin the changelog file.