summaryrefslogtreecommitdiff
path: root/Command/Fsck.hs
Commit message (Collapse)AuthorAge
* fsck: When the only copy of a file is in a dead repository, mention the ↵Gravatar Joey Hess2016-02-19
| | | | repository.
* fsck: Populate unlocked files in v6 repositories whose content is present in ↵Gravatar Joey Hess2016-02-14
| | | | | | annex/objects but didn't reach the work tree. This also handles fixing up after f9dfeaf801da2e4d5879b3de5895dc3cef68a329
* fsck: Detect and fix missing associated file mappings in v6 repositories.Gravatar Joey Hess2016-02-14
| | | | | This also handles fixing up after the bad data written by f9dfeaf801da2e4d5879b3de5895dc3cef68a329.
* files with only 1 linkCount may still be unlockedGravatar Joey Hess2016-02-14
| | | | When on crippled filesystem, or without annex.thin set.
* clean upGravatar Joey Hess2016-02-14
|
* remove 163 lines of code without changing anything except importsGravatar Joey Hess2016-01-20
|
* persistent-sqlite is now a hard build dependency, since v6 repository mode ↵Gravatar Joey Hess2015-12-26
| | | | needs it.
* recent fsck changes caused ugly message when object was not presentGravatar Joey Hess2015-12-15
|
* changes for v6 broke fsck in direct modeGravatar Joey Hess2015-12-15
|
* fsck for v6 unlocked filesGravatar Joey Hess2015-12-11
| | | | | | | | This only adds 1 stat to each file fscked for locked files, so added overhead is minimal. For unlocked files it has to access the database to see if a file is modified.
* fsck: Failed to honor annex.diskreserve when checking a remote.Gravatar Joey Hess2015-12-11
|
* display a message in the unlikely scenario of fsking a dead repositoryGravatar Joey Hess2015-11-10
|
* fsck: When fscking a dead repo, avoid incorrect "fixing location log" message.Gravatar Joey Hess2015-11-10
| | | | | keyLocations doesn't return locations in dead repos, but if we're fscking a dead repo, we want to look at what locations are actually logged for it.
* parallel fsck (yes, these changes are all it takes now!)Gravatar Joey Hess2015-11-04
|
* other 80% of avoding verification when hard linking to objects in shared repoGravatar Joey Hess2015-10-02
| | | | | | | | | | | | | | | | | | | | In c3b38fb2a075b4250e867ebd910324c65712c747, it actually only handled uploading objects to a shared repository. To avoid verification when downloading objects from a shared repository, was a lot harder. On the plus side, if the process of downloading a file from a remote is able to verify its content on the side, the remote can indicate this now, and avoid the extra post-download verification. As of yet, I don't have any remotes (except Git) using this ability. Some more work would be needed to support it in special remotes. It would make sense for tahoe to implicitly verify things downloaded from it; as long as you trust your tahoe server (which typically runs locally), there's cryptographic integrity. OTOH, despite bup being based on shas, a bup repo under an attacker's control could have the git ref used for an object changed, and so a bup repo shouldn't implicitly verify. Indeed, tahoe seems unique in being trustworthy enough to implicitly verify.
* rename fsckKey to verifyKeyContentGravatar Joey Hess2015-10-01
| | | | No behavior changes.
* Improve bash completion, so it completes names of remotes and backends in ↵Gravatar Joey Hess2015-09-14
| | | | | | | | | appropriate places. Not necessarily everywhere, but a lot of the most often used places. Re the use of .Internal, see https://github.com/pcapriotti/optparse-applicative/issues/155
* Fix building without database.Gravatar Joey Hess2015-08-23
| | | | | | | | Ben Boeckel had a patch, but.. Actually, that was not the only place that used ScheduleIncremental when built w/o database. Since the data type doesn't need database stuff, I've instead fixed this build problem by exposing the ScheduleIncremental constructor to database-less builds.
* Improve shutdown due to --time-limit, especially for fsckGravatar Joey Hess2015-07-31
| | | | | | | | | | | | | | | * Perform a clean shutdown when --time-limit is reached. This includes running queued git commands, and cleanup actions normally run when a command is finished. * fsck: Commit incremental fsck database when --time-limit is reached. Previously, some of the last files fscked did not make it into the database when using --time-limit. Note that this changes Annex.addCleanup hooks, to run after --time-limit expires. Fsck was using such a hook to clean up after a --incremental-schedule, and that shouldn't run when --time-limit exipires it. So, instead, moved that cleanup code to be run by cleanupIncremental. Resulted in some data type juggling.
* Support building without persistent database on for systems that lack TH. ↵Gravatar Joey Hess2015-07-25
| | | | This removes support for incremental fsck.
* finished converting all the main optionsGravatar Joey Hess2015-07-10
|
* wipGravatar Joey Hess2015-07-09
|
* converted copy and moveGravatar Joey Hess2015-07-09
| | | | Got a little tricky..
* use Alternative for parsing KeyOptionsGravatar Joey Hess2015-07-09
|
* use Alternative when parsing mutually exclusive fsck optionsGravatar Joey Hess2015-07-09
|
* formattingGravatar Joey Hess2015-07-09
|
* finalOpt is the same as optionalGravatar Joey Hess2015-07-09
|
* wipGravatar Joey Hess2015-07-08
|
* converted fsck's options to optparse-applicativeGravatar Joey Hess2015-07-08
| | | | Global options and seeking and key options are still to be done.
* convert all commands to work with optparse-applicativeGravatar Joey Hess2015-07-08
| | | | Still no options though.
* started converting to use optparse-applicativeGravatar Joey Hess2015-07-08
| | | | | | | | | | | | This is a work in progress. It compiles and is able to do basic command dispatch, including git autocorrection, while using optparse-applicative for the core commandline parsing. * Many commands are temporarily disabled before conversion. * Options are not wired in yet. * cmdnorepo actions don't work yet. Also, removed the [Command] list, which was only used in one place.
* add a hint about marking a key deadGravatar Joey Hess2015-06-09
|
* fsck: Ignore keys that are known to be dead when running in --all mode or a ↵Gravatar Joey Hess2015-06-09
| | | | in a bare repo. Otherwise, still reports files with lost contents, even if the content is dead.
* Take space that will be used by running downloads into account when checking ↵Gravatar Joey Hess2015-05-12
| | | | annex.diskreserve.
* Merge branch 'master' into concurrentprogressGravatar Joey Hess2015-05-12
|\ | | | | | | | | | | | | | | | | | | | | | | Conflicts: Command/Fsck.hs Messages.hs Remote/Directory.hs Remote/Git.hs Remote/Helper/Special.hs Types/Remote.hs debian/changelog git-annex.cabal
| * support time-1.5.0Gravatar Joey Hess2015-05-10
| | | | | | | | | | | | | | This no longer uses old-locale's defaultTimeLocale, but provides one of its own. Factored out a Logs.TimeStamp.
| * fsck: Ignore error recording the fsck in the activity log, which can happen ↵Gravatar Joey Hess2015-05-06
| | | | | | | | when running fsck in a read-only repository. Closes: #698559 (fsck can still need to write to the repository if it find problems, but a successful fsck can be done read-only)
| * refactorGravatar Joey Hess2015-04-30
| |
| * Fix bogus failure of fsck --fast.Gravatar Joey Hess2015-04-27
| |
| * fsck --from remote: Avoid downloading a key if it would go over the ↵Gravatar Joey Hess2015-04-18
| | | | | | | | annex.diskreserve limit.
| * fsck --from remote: When bad content is found in the remote, and the local ↵Gravatar Joey Hess2015-04-18
| | | | | | | | repo does not have a copy of the content, preserve the bad content in .git/annex/bad/ to avoid further data loss.
* | add filename to progress bar, and display ok/failed at endGravatar Joey Hess2015-04-14
|/ | | | This needed plumbing an AssociatedFile through retrieveKeyFileCheap.
* rethought distributed fsck; instead add activity.log and expire commandGravatar Joey Hess2015-04-05
| | | | This is much more space efficient!
* fsck: Added --distributed and --expire options, for distributed fsck.Gravatar Joey Hess2015-04-01
|
* --auto is no longer a global option; only get, drop, and copy accept it.Gravatar Joey Hess2015-03-25
| | | | Not a behavior change unless you were passing it to a command that ignored it.
* fsck: Multiple incremental fscks of different repos (some remote) can now be ↵Gravatar Joey Hess2015-02-17
| | | | in progress at the same time in the same repo without it getting confused about which files have been checked for which remotes.
* avoid crash when starting fsck --incremental when one is already runningGravatar Joey Hess2015-02-17
| | | | | | | | | | | Turns out sqlite does not like having its database deleted out from underneath it. It might suffice to empty the table, but I would rather start each fsck over with a new database, so I added a lock file, and running incremental fscks use a shared lock. This leaves one concurrency bug left; running two concurrent fsck --more will lead to: "SQLite3 returned ErrorBusy while attempting to perform step." and one or both will fail. This is a concurrent writers problem.
* commit new transaction after 60 secondsGravatar Joey Hess2015-02-16
| | | | | | | | | | | | | | Database.Handle can now be given a CommitPolicy, making it easy to specify transaction granularity. Benchmarking the old git-annex incremental fsck that flips sticky bits to the new that uses sqlite, running in a repo with 37000 annexed files, both from cold cache: old: 6m6.906s new: 6m26.913s This commit was sponsored by TasLUG.
* commit more transactions when fsckingGravatar Joey Hess2015-02-16
| | | | | | This makes interrupt and resume work, robustly. But, incremental fsck is slowed down by all those transactions..
* convert incremental fsck to using sqlite databaseGravatar Joey Hess2015-02-16
| | | | | | | | | | | | | | | | | Did not keep backwards compat for sticky bit records. An incremental fsck that is already in progress will start over on upgrade to this version. This is not yet ready for merging. The autobuilders need to have sqlite installed. Also, interrupting a fsck --incremental does not commit the database. So, resuming with fsck --more restarts from beginning. Memory: Constant during a fsck of tens of thousands of files. (But, it does seem to buffer whole transation in memory, so may really scale with number of files.) CPU: ?
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 00:16:51 +0000