7ce30b534f
In indirect mode, now checks the inode cache to detect changes to a file. Note that a file can still be changed if a process has it open for write, after landing in the annex. In direct mode, some checking of the inode cache was done before, but from a much later point, so fewer modifications could be detected. Now it's as good as indirect mode. On crippled filesystems, no lock down is done before starting to add a file, so checking the inode cache is the only protection we have.
29 lines
859 B
Haskell
29 lines
859 B
Haskell
{- KeySource data type
|
|
-
|
|
- Copyright 2012 Joey Hess <joey@kitenet.net>
|
|
-
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
-}
|
|
|
|
module Types.KeySource where
|
|
|
|
import Utility.InodeCache
|
|
|
|
{- When content is in the process of being added to the annex,
|
|
- and a Key generated from it, this data type is used.
|
|
-
|
|
- The contentLocation may be different from the filename
|
|
- associated with the key. For example, the add command
|
|
- may temporarily hard link the content into a lockdown directory
|
|
- for checking. The migrate command uses the content
|
|
- of a different Key.
|
|
-
|
|
- The inodeCache can be used to detect some types of modifications to
|
|
- files that may be made while they're in the process of being added.
|
|
-}
|
|
data KeySource = KeySource
|
|
{ keyFilename :: FilePath
|
|
, contentLocation :: FilePath
|
|
, inodeCache :: Maybe InodeCache
|
|
}
|
|
deriving (Show)
|