git-annex/Test.hs

1991 lines
76 KiB
Haskell
Raw Normal View History

{- git-annex test suite
-
- Copyright 2010-2021 Joey Hess <id@joeyh.name>
-
- Licensed under the GNU AGPL version 3 or higher.
-}
2013-05-17 20:45:44 +00:00
{-# LANGUAGE CPP #-}
module Test where
2016-01-06 17:44:12 +00:00
import Types.Test
import Types.RepoVersion
import Test.Framework
import Options.Applicative.Types
import Test.Tasty
import Test.Tasty.Runners
import Test.Tasty.HUnit
import Test.Tasty.QuickCheck
import Test.Tasty.Ingredients.Rerun
import Test.Tasty.Options
import Options.Applicative (switch, long, help, internal)
2011-01-12 05:58:23 +00:00
import qualified Data.Map as M
import qualified Data.ByteString.Lazy.UTF8 as BU8
import System.Environment
import Control.Concurrent.STM hiding (check)
2010-11-02 21:08:16 +00:00
import Common
import CmdLine.GitAnnex.Options
import qualified Utility.ShellEscape
import qualified Utility.RawFilePath as R
2011-01-11 19:43:29 +00:00
import qualified Annex
2011-12-13 19:22:43 +00:00
import qualified Git.Filename
import qualified Git.Types
import qualified Git.Ref
import qualified Git.LsTree
import qualified Git.FilePath
import qualified Annex.Locations
2017-10-24 16:24:06 +00:00
#ifndef mingw32_HOST_OS
import qualified Types.GitConfig
2017-10-24 16:24:06 +00:00
#endif
2012-12-20 03:43:15 +00:00
import qualified Types.TrustLevel
import qualified Types
import qualified Logs.MapLog
2011-10-15 20:21:08 +00:00
import qualified Logs.Trust
import qualified Logs.Remote
2012-05-06 00:11:08 +00:00
import qualified Logs.Unused
import qualified Logs.Transfer
import qualified Logs.Presence
import qualified Logs.ContentIdentifier
import qualified Logs.PreferredContent
import qualified Types.MetaData
2011-03-27 20:58:28 +00:00
import qualified Remote
2017-02-24 17:42:30 +00:00
import qualified Key
import qualified Config
import qualified Config.Cost
2011-04-21 20:56:24 +00:00
import qualified Crypto
import qualified Database.Keys
2015-12-15 19:34:28 +00:00
import qualified Annex.WorkTree
2014-01-26 20:36:31 +00:00
import qualified Annex.Init
import qualified Annex.CatFile
import qualified Annex.Path
import qualified Annex.VectorClock
import qualified Annex.AdjustedBranch
import qualified Annex.View
import qualified Annex.View.ViewedFile
import qualified Logs.View
import qualified Command.TestRemote
import qualified Utility.Path.Tests
2011-09-28 19:17:45 +00:00
import qualified Utility.FileMode
import qualified BuildInfo
import qualified Utility.Format
import qualified Utility.Verifiable
import qualified Utility.Process
import qualified Utility.Misc
2013-02-14 20:17:40 +00:00
import qualified Utility.InodeCache
2013-05-11 22:23:41 +00:00
import qualified Utility.Env
import qualified Utility.Env.Set
import qualified Utility.Matcher
import qualified Utility.Hash
import qualified Utility.Scheduled
2015-11-17 19:49:22 +00:00
import qualified Utility.Scheduled.QuickCheck
import qualified Utility.HumanTime
import qualified Utility.Base64
import qualified Utility.Tmp.Dir
import qualified Utility.FileSystemEncoding
import qualified Utility.Aeson
2019-11-14 18:02:09 +00:00
import qualified Utility.CopyFile
2020-07-02 16:18:42 +00:00
import qualified Types.Remote
2014-10-16 19:54:02 +00:00
#ifndef mingw32_HOST_OS
import qualified Remote.Helper.Encryptable
import qualified Types.Crypto
import qualified Utility.Gpg
2013-05-17 20:51:46 +00:00
#endif
2010-11-02 20:49:35 +00:00
2016-01-06 17:44:12 +00:00
optParser :: Parser TestOptions
optParser = TestOptions
<$> snd tastyParser
2016-01-06 17:44:12 +00:00
<*> switch
( long "keep-failures"
<> help "preserve repositories on test failure"
)
<*> switch
( long "fakessh"
<> internal
)
<*> cmdParams "non-options are for internal use only"
tastyParser :: ([String], Parser Test.Tasty.Options.OptionSet)
#if MIN_VERSION_tasty(1,3,0)
tastyParser = go
#else
tastyParser = ([], go)
#endif
where
go = suiteOptionParser ingredients (tests False True mempty)
runner :: TestOptions -> IO ()
runner opts
| fakeSsh opts = runFakeSsh (internalData opts)
| otherwise = runsubprocesstests =<< Utility.Env.getEnv subenv
where
-- Run git-annex test in a subprocess, so that any files
-- it may open will be closed before running finalCleanup.
-- This should prevent most failures to clean up after the test
-- suite.
subenv = "GIT_ANNEX_TEST_SUBPROCESS"
runsubprocesstests Nothing = do
let warnings = fst tastyParser
unless (null warnings) $ do
hPutStrLn stderr "warnings from tasty:"
mapM_ (hPutStrLn stderr) warnings
pp <- Annex.Path.programPath
Utility.Env.Set.setEnv subenv "1" True
ps <- getArgs
exitcode <- withCreateProcess (proc pp ps) $
\_ _ _ pid -> waitForProcess pid
unless (keepFailuresOption opts) finalCleanup
exitWith exitcode
runsubprocesstests (Just _) = isolateGitConfig $ do
ensuretmpdir
crippledfilesystem <- fst <$> Annex.Init.probeCrippledFileSystem'
(toRawFilePath tmpdir)
Nothing Nothing
adjustedbranchok <- Annex.AdjustedBranch.isGitVersionSupported
case tryIngredients ingredients (tastyOptionSet opts) (tests crippledfilesystem adjustedbranchok opts) of
Nothing -> error "No tests found!?"
Just act -> ifM act
( exitSuccess
, do
putStrLn " (Failures above could be due to a bug in git-annex, or an incompatibility"
putStrLn " with utilities, such as git, installed on this system.)"
exitFailure
)
ingredients :: [Ingredient]
ingredients =
[ listingTests
, rerunningTests [consoleTestReporter]
]
tests :: Bool -> Bool -> TestOptions -> TestTree
tests crippledfilesystem adjustedbranchok opts =
testGroup "Tests" $ properties
: withTestMode remotetestmode Nothing testRemotes
: map (\(d, te) -> withTestMode te (Just initTests) (unitTests d)) testmodes
2015-12-15 21:19:26 +00:00
where
testmodes = catMaybes
[ canadjust ("v8 adjusted unlocked branch", (testMode opts (RepoVersion 8)) { adjustedUnlockedBranch = True })
, unlesscrippled ("v8 unlocked", (testMode opts (RepoVersion 8)) { unlockedFiles = True })
, unlesscrippled ("v8 locked", testMode opts (RepoVersion 8))
2015-12-28 16:57:42 +00:00
]
remotetestmode = testMode opts (RepoVersion 8)
2016-02-16 20:02:54 +00:00
unlesscrippled v
| crippledfilesystem = Nothing
| otherwise = Just v
canadjust v
| adjustedbranchok = Just v
| otherwise = Nothing
2015-07-08 04:03:28 +00:00
properties :: TestTree
properties = localOption (QuickCheckTests 1000) $ testGroup "QuickCheck" $
[ testProperty "prop_encode_decode_roundtrip" Git.Filename.prop_encode_decode_roundtrip
, testProperty "prop_encode_c_decode_c_roundtrip" Utility.Format.prop_encode_c_decode_c_roundtrip
2017-02-24 17:42:30 +00:00
, testProperty "prop_isomorphic_key_encode" Key.prop_isomorphic_key_encode
, testProperty "prop_isomorphic_shellEscape" Utility.ShellEscape.prop_isomorphic_shellEscape
, testProperty "prop_isomorphic_shellEscape_multiword" Utility.ShellEscape.prop_isomorphic_shellEscape_multiword
2015-11-16 18:37:31 +00:00
, testProperty "prop_isomorphic_configEscape" Logs.Remote.prop_isomorphic_configEscape
, testProperty "prop_parse_show_Config" Logs.Remote.prop_parse_show_Config
, testProperty "prop_upFrom_basics" Utility.Path.Tests.prop_upFrom_basics
, testProperty "prop_relPathDirToFileAbs_basics" Utility.Path.Tests.prop_relPathDirToFileAbs_basics
, testProperty "prop_relPathDirToFileAbs_regressionTest" Utility.Path.Tests.prop_relPathDirToFileAbs_regressionTest
, testProperty "prop_cost_sane" Config.Cost.prop_cost_sane
, testProperty "prop_matcher_sane" Utility.Matcher.prop_matcher_sane
, testProperty "prop_HmacSha1WithCipher_sane" Crypto.prop_HmacSha1WithCipher_sane
, testProperty "prop_VectorClock_sane" Annex.VectorClock.prop_VectorClock_sane
, testProperty "prop_addMapLog_sane" Logs.MapLog.prop_addMapLog_sane
, testProperty "prop_verifiable_sane" Utility.Verifiable.prop_verifiable_sane
, testProperty "prop_segment_regressionTest" Utility.Misc.prop_segment_regressionTest
, testProperty "prop_read_write_transferinfo" Logs.Transfer.prop_read_write_transferinfo
, testProperty "prop_read_show_inodecache" Utility.InodeCache.prop_read_show_inodecache
, testProperty "prop_parse_build_presence_log" Logs.Presence.prop_parse_build_presence_log
, testProperty "prop_parse_build_contentidentifier_log" Logs.ContentIdentifier.prop_parse_build_contentidentifier_log
, testProperty "prop_read_show_TrustLevel" Types.TrustLevel.prop_read_show_TrustLevel
, testProperty "prop_parse_build_TrustLevelLog" Logs.Trust.prop_parse_build_TrustLevelLog
2015-11-17 19:49:22 +00:00
, testProperty "prop_schedule_roundtrips" Utility.Scheduled.QuickCheck.prop_schedule_roundtrips
2014-04-12 18:19:56 +00:00
, testProperty "prop_past_sane" Utility.Scheduled.prop_past_sane
, testProperty "prop_duration_roundtrips" Utility.HumanTime.prop_duration_roundtrips
, testProperty "prop_metadata_sane" Types.MetaData.prop_metadata_sane
, testProperty "prop_metadata_serialize" Types.MetaData.prop_metadata_serialize
, testProperty "prop_branchView_legal" Logs.View.prop_branchView_legal
, testProperty "prop_viewPath_roundtrips" Annex.View.prop_viewPath_roundtrips
, testProperty "prop_view_roundtrips" Annex.View.prop_view_roundtrips
, testProperty "prop_viewedFile_rountrips" Annex.View.ViewedFile.prop_viewedFile_roundtrips
, testProperty "prop_b64_roundtrips" Utility.Base64.prop_b64_roundtrips
, testProperty "prop_standardGroups_parse" Logs.PreferredContent.prop_standardGroups_parse
] ++ map (uncurry testProperty) combos
where
combos = concat
[ Utility.Hash.props_hashes_stable
, Utility.Hash.props_macs_stable
]
2010-11-02 21:08:16 +00:00
testRemotes :: TestTree
2021-04-23 04:38:18 +00:00
testRemotes = testGroup "Remote Tests" $
-- These tests are failing in really strange ways on Windows,
-- apparently not due to an actual problem with the remotes being
-- tested, so are disabled there.
#ifdef mingw32_HOST_OS
filter (\_ -> False)
#endif
[ testGitRemote
, testDirectoryRemote
]
testGitRemote :: TestTree
testGitRemote = testRemote False "git" $ \remotename -> do
git "clone" [".", "remotedir"] "git clone"
git "remote" ["add", remotename, "remotedir"] "git remote add"
testDirectoryRemote :: TestTree
testDirectoryRemote = testRemote True "directory" $ \remotename -> do
createDirectory "remotedir"
git_annex "initremote"
[ remotename
, "type=directory"
, "--quiet"
, "directory=remotedir"
, "encryption=none"
] "init"
testRemote :: Bool -> String -> (String -> IO ()) -> TestTree
testRemote testvariants remotetype setupremote =
withResource newEmptyTMVarIO (const noop) $ \getv ->
testGroup ("testremote type " ++ remotetype) $ concat
[ [testCase "init" (prep getv)]
, go getv
]
where
reponame = "test repo"
remotename = "testremote"
basesz = 1024 * 1024
keysizes = Command.TestRemote.keySizes basesz False
prep getv = do
d <- newmainrepodir
setmainrepodir d
innewrepo $ do
git_annex "init" [reponame, "--quiet"] "init"
setupremote remotename
r <- annexeval $ either error return
=<< Remote.byName' remotename
cache <- Command.TestRemote.newRemoteVariantCache
unavailr <- annexeval $ Types.Remote.mkUnavailable r
exportr <- annexeval $ Command.TestRemote.exportTreeVariant cache r
ks <- annexeval $ mapM Command.TestRemote.randKey keysizes
v <- getv
cv <- annexeval cache
liftIO $ atomically $ putTMVar v
(r, (unavailr, (exportr, (ks, cv))))
go getv = Command.TestRemote.mkTestTrees runannex mkrs mkunavailr mkexportr mkks
where
runannex = inmainrepo . annexeval
mkrs = if testvariants
then Command.TestRemote.remoteVariants cache mkr basesz False
else [fmap (fmap Just) mkr]
mkr = descas (remotetype ++ " remote") (fst <$> v)
mkunavailr = fst . snd <$> v
2020-04-30 17:13:08 +00:00
mkexportr = fst . snd . snd <$> v
mkks = map (\(sz, n) -> desckeysize sz (getk n))
(zip keysizes [0..])
getk n = fmap (!! n) (fst . snd . snd . snd <$> v)
cache = snd . snd . snd . snd <$> v
v = liftIO $ atomically . readTMVar =<< getv
descas = Command.TestRemote.Described
desckeysize sz = descas ("key size " ++ show sz)
{- These tests set up the test environment, but also test some basic parts
- of git-annex. They are always run before the unitTests. -}
initTests :: TestTree
initTests = testGroup "Init Tests"
[ testCase "init" test_init
, testCase "add" test_add
]
unitTests :: String -> TestTree
unitTests note = testGroup ("Unit Tests " ++ note)
[ testCase "add dup" test_add_dup
, testCase "add extras" test_add_extras
, testCase "ignore deleted files" test_ignore_deleted_files
2020-07-13 16:53:09 +00:00
, testCase "metadata" test_metadata
2019-03-06 20:49:33 +00:00
, testCase "export_import" test_export_import
, testCase "export_import_subdir" test_export_import_subdir
, testCase "shared clone" test_shared_clone
, testCase "log" test_log
, testCase "view" test_view
, testCase "magic" test_magic
, testCase "import" test_import
, testCase "reinject" test_reinject
, testCase "unannex (no copy)" test_unannex_nocopy
, testCase "unannex (with copy)" test_unannex_withcopy
, testCase "drop (no remote)" test_drop_noremote
, testCase "drop (with remote)" test_drop_withremote
, testCase "drop (untrusted remote)" test_drop_untrustedremote
, testCase "get" test_get
2017-03-17 23:18:45 +00:00
, testCase "get (ssh remote)" test_get_ssh_remote
, testCase "move" test_move
2017-03-17 23:18:45 +00:00
, testCase "move (ssh remote)" test_move_ssh_remote
, testCase "move (numcopies)" test_move_numcopies
, testCase "copy" test_copy
, testCase "lock" test_lock
, testCase "lock --force" test_lock_force
, testCase "edit (no pre-commit)" test_edit
, testCase "edit (pre-commit)" test_edit_precommit
, testCase "partial commit" test_partial_commit
, testCase "fix" test_fix
, testCase "trust" test_trust
, testCase "fsck (basics)" test_fsck_basic
, testCase "fsck (bare)" test_fsck_bare
, testCase "fsck (local untrusted)" test_fsck_localuntrusted
, testCase "fsck (remote untrusted)" test_fsck_remoteuntrusted
, testCase "fsck --from remote" test_fsck_fromremote
, testCase "conversion git to annexed" test_conversion_git_to_annexed
, testCase "conversion annexed to git" test_conversion_annexed_to_git
, testCase "migrate" test_migrate
, testCase "migrate (via gitattributes)" test_migrate_via_gitattributes
, testCase "unused" test_unused
, testCase "describe" test_describe
, testCase "find" test_find
, testCase "merge" test_merge
, testCase "info" test_info
, testCase "version" test_version
, testCase "sync" test_sync
2019-11-14 18:02:09 +00:00
, testCase "concurrent get of dup key regression" test_concurrent_get_of_dup_key_regression
, testCase "union merge regression" test_union_merge_regression
, testCase "adjusted branch merge regression" test_adjusted_branch_merge_regression
, testCase "adjusted branch subtree regression" test_adjusted_branch_subtree_regression
, testCase "conflict resolution" test_conflict_resolution
, testCase "conflict resolution (adjusted branch)" test_conflict_resolution_adjusted_branch
, testCase "conflict resolution movein regression" test_conflict_resolution_movein_regression
, testCase "conflict resolution (mixed directory and file)" test_mixed_conflict_resolution
, testCase "conflict resolution symlink bit" test_conflict_resolution_symlink_bit
, testCase "conflict resolution (uncommitted local file)" test_uncommitted_conflict_resolution
, testCase "conflict resolution (removed file)" test_remove_conflict_resolution
, testCase "conflict resolution (nonannexed file)" test_nonannexed_file_conflict_resolution
, testCase "conflict resolution (nonannexed symlink)" test_nonannexed_symlink_conflict_resolution
, testCase "conflict resolution (mixed locked and unlocked file)" test_mixed_lock_conflict_resolution
, testCase "map" test_map
, testCase "uninit" test_uninit
, testCase "uninit (in git-annex branch)" test_uninit_inbranch
, testCase "upgrade" test_upgrade
, testCase "whereis" test_whereis
, testCase "hook remote" test_hook_remote
, testCase "directory remote" test_directory_remote
, testCase "rsync remote" test_rsync_remote
, testCase "bup remote" test_bup_remote
, testCase "crypto" test_crypto
, testCase "preferred content" test_preferred_content
, testCase "required_content" test_required_content
, testCase "add subdirs" test_add_subdirs
2015-02-10 19:20:07 +00:00
, testCase "addurl" test_addurl
]
-- this test case creates the main repo
test_init :: Assertion
test_init = innewrepo $ do
2015-12-16 17:14:18 +00:00
ver <- annexVersion <$> getTestMode
git_annex "init" [reponame, "--version", show (fromRepoVersion ver)] "init"
2015-12-15 21:19:26 +00:00
setupTestMode
2012-11-11 04:51:07 +00:00
where
reponame = "test repo"
-- this test case runs in the main repo, to set up a basic
-- annexed file that later tests will use
test_add :: Assertion
test_add = inmainrepo $ do
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent annexedfile $ content annexedfile
add_annex annexedfile "add"
annexed_present annexedfile
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent sha1annexedfile $ content sha1annexedfile
git_annex "add" [sha1annexedfile, "--backend=SHA1"] "add with SHA1"
whenM (unlockedFiles <$> getTestMode) $
git_annex "unlock" [sha1annexedfile] "unlock"
annexed_present sha1annexedfile
checkbackend sha1annexedfile backendSHA1
writecontent ingitfile $ content ingitfile
git "add" [ingitfile] "git add"
git "commit" ["-q", "-m", "commit"] "git commit"
git_annex "add" [ingitfile] "add ingitfile should be no-op"
unannexed ingitfile
test_add_dup :: Assertion
test_add_dup = intmpclonerepo $ do
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent annexedfiledup $ content annexedfiledup
add_annex annexedfiledup "add of second file with same content failed"
annexed_present annexedfiledup
annexed_present annexedfile
test_add_extras :: Assertion
test_add_extras = intmpclonerepo $ do
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent wormannexedfile $ content wormannexedfile
git_annex "add" [wormannexedfile, "--backend=WORM"] "add with WORM"
whenM (unlockedFiles <$> getTestMode) $
git_annex "unlock" [wormannexedfile] "unlock"
annexed_present wormannexedfile
checkbackend wormannexedfile backendWORM
test_ignore_deleted_files :: Assertion
test_ignore_deleted_files = intmpclonerepo $ do
git_annex "get" [annexedfile] "get"
git_annex_expectoutput "find" [] [annexedfile]
removeWhenExistsWith R.removeLink (toRawFilePath annexedfile)
-- A file that has been deleted, but the deletion not staged,
-- is a special case; make sure git-annex skips these.
git_annex_expectoutput "find" [] []
2020-07-13 16:53:09 +00:00
test_metadata :: Assertion
test_metadata = intmpclonerepo $ do
git_annex "metadata" ["-s", "foo=bar", annexedfile] "set metadata"
2020-07-13 16:53:09 +00:00
git_annex_expectoutput "find" ["--metadata", "foo=bar"] [annexedfile]
git_annex_expectoutput "find" ["--metadata", "foo=other"] []
writecontent annexedfiledup $ content annexedfiledup
add_annex annexedfiledup "add of second file with same content failed"
2020-07-13 16:53:09 +00:00
annexed_present annexedfiledup
git_annex_expectoutput "find" ["--metadata", "foo=bar"]
[annexedfile, annexedfiledup]
git_annex_shouldfail "metadata" ["--remove", "foo", "."]
"removing metadata from dir with multiple files not allowed"
2020-07-13 16:53:09 +00:00
git_annex "metadata" ["--remove", "foo", annexedfile]
"removing metadata"
2020-07-13 16:53:09 +00:00
git_annex_expectoutput "find" ["--metadata", "foo=bar"] []
git_annex "metadata" ["--force", "-s", "foo=bar", "."]
"recursively set metadata force"
2020-07-13 16:53:09 +00:00
test_shared_clone :: Assertion
test_shared_clone = intmpsharedclonerepo $ do
v <- catchMaybeIO $ Utility.Process.readProcess "git"
[ "config"
, "--bool"
, "--get"
, "annex.hardlink"
]
v == Just "true\n"
@? "shared clone of repo did not get annex.hardlink set"
test_log :: Assertion
test_log = intmpclonerepo $ do
git_annex "log" [annexedfile] "log"
test_view :: Assertion
test_view = intmpclonerepo $ do
git_annex "metadata" ["-s", "test=test1", annexedfile] "metadata"
git_annex "metadata" ["-s", "test=test2", sha1annexedfile] "metadata"
git_annex "view" ["test=test1"] "entering view"
checkexists annexedfile
checkdoesnotexist sha1annexedfile
test_magic :: Assertion
test_magic = intmpclonerepo $ do
#ifdef WITH_MAGICMIME
git "config" ["annex.largefiles", "mimeencoding=binary"]
"git config annex.largefiles"
writeFile "binary" "\127"
writeFile "text" "test\n"
git_annex "add" ["binary", "text"]
"git-annex add with mimeencoding in largefiles"
git_annex "sync" []
"git-annex sync"
(isJust <$> annexeval (Annex.CatFile.catKeyFile (encodeBS "binary")))
@? "binary file not added to annex despite mimeencoding config"
(isNothing <$> annexeval (Annex.CatFile.catKeyFile (encodeBS "text")))
@? "non-binary file got added to annex despite mimeencoding config"
#else
return ()
#endif
test_import :: Assertion
test_import = intmpclonerepo $ Utility.Tmp.Dir.withTmpDir "importtest" $ \importdir -> do
(toimport1, importf1, imported1) <- mktoimport importdir "import1"
git_annex "import" [toimport1] "import"
annexed_present_imported imported1
checkdoesnotexist importf1
(toimport2, importf2, imported2) <- mktoimport importdir "import2"
git_annex "import" [toimport2] "import of duplicate"
annexed_present_imported imported2
checkdoesnotexist importf2
(toimport3, importf3, imported3) <- mktoimport importdir "import3"
git_annex "import" ["--skip-duplicates", toimport3]
"import of duplicate with --skip-duplicates"
checkdoesnotexist imported3
checkexists importf3
git_annex "import" ["--clean-duplicates", toimport3]
"import of duplicate with --clean-duplicates"
checkdoesnotexist imported3
checkdoesnotexist importf3
(toimport4, importf4, imported4) <- mktoimport importdir "import4"
git_annex "import" ["--deduplicate", toimport4] "import --deduplicate"
checkdoesnotexist imported4
checkdoesnotexist importf4
(toimport5, importf5, imported5) <- mktoimport importdir "import5"
git_annex "import" ["--duplicate", toimport5] "import --duplicate"
annexed_present_imported imported5
checkexists importf5
git_annex "drop" ["--force", imported1, imported2, imported5] "drop"
annexed_notpresent_imported imported2
(toimportdup, importfdup, importeddup) <- mktoimport importdir "importdup"
git_annex_shouldfail "import" ["--clean-duplicates", toimportdup]
"import of missing duplicate with --clean-duplicates not allowed"
checkdoesnotexist importeddup
checkexists importfdup
where
mktoimport importdir subdir = do
createDirectory (importdir </> subdir)
let importf = subdir </> "f"
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent (importdir </> importf) (content importf)
return (importdir </> subdir, importdir </> importf, importf)
test_reinject :: Assertion
test_reinject = intmpclonerepo $ do
git_annex "drop" ["--force", sha1annexedfile] "drop"
2016-01-05 21:19:30 +00:00
annexed_notpresent sha1annexedfile
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent tmp $ content sha1annexedfile
key <- Key.serializeKey <$> getKey backendSHA1 tmp
git_annex "reinject" [tmp, sha1annexedfile] "reinject"
2016-01-05 21:19:30 +00:00
annexed_present sha1annexedfile
git_annex "fromkey" [key, sha1annexedfiledup] "fromkey for dup"
whenM (unlockedFiles <$> getTestMode) $
git_annex "unlock" [sha1annexedfiledup] "unlock"
annexed_present sha1annexedfiledup
2012-11-11 04:51:07 +00:00
where
tmp = "tmpfile"
2011-01-11 23:59:11 +00:00
test_unannex_nocopy :: Assertion
test_unannex_nocopy = intmpclonerepo $ do
annexed_notpresent annexedfile
git_annex "unannex" [annexedfile] "unannex with no copy"
annexed_notpresent annexedfile
test_unannex_withcopy :: Assertion
test_unannex_withcopy = intmpclonerepo $ do
git_annex "get" [annexedfile] "get"
annexed_present annexedfile
git_annex "unannex" [annexedfile, sha1annexedfile] "unannex"
unannexed annexedfile
git_annex "unannex" [annexedfile] "unannex on non-annexed file"
unannexed annexedfile
git_annex "unannex" [ingitfile] "unannex ingitfile should be no-op"
unannexed ingitfile
2011-01-07 01:39:26 +00:00
test_drop_noremote :: Assertion
test_drop_noremote = intmpclonerepo $ do
git_annex "get" [annexedfile] "get"
git "remote" ["rm", "origin"] "git remote rm origin"
git_annex_shouldfail "drop" [annexedfile] "drop with no known copy of file not allowed"
annexed_present annexedfile
git_annex "drop" ["--force", annexedfile] "drop --force"
annexed_notpresent annexedfile
git_annex "drop" [annexedfile] "drop of dropped file"
git_annex "drop" [ingitfile] "drop ingitfile should be no-op"
unannexed ingitfile
test_drop_withremote :: Assertion
test_drop_withremote = intmpclonerepo $ do
git_annex "get" [annexedfile] "get"
annexed_present annexedfile
git_annex "numcopies" ["2"] "numcopies config"
git_annex_shouldfail "drop" [annexedfile] "drop with numcopies not satisfied is not allowed"
git_annex "numcopies" ["1"] "numcopies config"
git_annex "drop" [annexedfile] "drop when origin has copy"
annexed_notpresent annexedfile
-- make sure that the correct symlink is staged for the file
-- after drop
git_annex_expectoutput "status" [] []
inmainrepo $ annexed_present annexedfile
test_drop_untrustedremote :: Assertion
test_drop_untrustedremote = intmpclonerepo $ do
git_annex "untrust" ["origin"] "untrust of origin"
git_annex "get" [annexedfile] "get"
annexed_present annexedfile
git_annex_shouldfail "drop" [annexedfile] "drop with only an untrusted copy of the file should fail"
annexed_present annexedfile
inmainrepo $ annexed_present annexedfile
test_get :: Assertion
test_get = test_get' intmpclonerepo
test_get_ssh_remote :: Assertion
test_get_ssh_remote =
#ifndef mingw32_HOST_OS
test_get' (with_ssh_origin intmpclonerepo)
#else
noop
#endif
test_get' :: (Assertion -> Assertion) -> Assertion
test_get' setup = setup $ do
inmainrepo $ annexed_present annexedfile
annexed_notpresent annexedfile
git_annex "get" [annexedfile] "get of file"
inmainrepo $ annexed_present annexedfile
annexed_present annexedfile
git_annex "get" [annexedfile] "get of file already here"
inmainrepo $ annexed_present annexedfile
annexed_present annexedfile
inmainrepo $ unannexed ingitfile
unannexed ingitfile
git_annex "get" [ingitfile] "get ingitfile should be no-op"
inmainrepo $ unannexed ingitfile
unannexed ingitfile
2011-01-07 05:02:06 +00:00
test_move :: Assertion
2017-03-17 23:18:45 +00:00
test_move = test_move' intmpclonerepo
test_move_ssh_remote :: Assertion
test_move_ssh_remote =
#ifndef mingw32_HOST_OS
test_move' (with_ssh_origin intmpclonerepo)
#else
noop
#endif
2017-03-17 23:18:45 +00:00
test_move' :: (Assertion -> Assertion) -> Assertion
test_move' setup = setup $ do
annexed_notpresent annexedfile
inmainrepo $ annexed_present annexedfile
git_annex "move" ["--from", "origin", annexedfile] "move --from of file"
annexed_present annexedfile
inmainrepo $ annexed_notpresent annexedfile
git_annex "move" ["--from", "origin", annexedfile] "move --from of file already here"
annexed_present annexedfile
inmainrepo $ annexed_notpresent annexedfile
git_annex "move" ["--to", "origin", annexedfile] "move --to of file"
inmainrepo $ annexed_present annexedfile
annexed_notpresent annexedfile
git_annex "move" ["--to", "origin", annexedfile] "move --to of file already there"
inmainrepo $ annexed_present annexedfile
annexed_notpresent annexedfile
unannexed ingitfile
inmainrepo $ unannexed ingitfile
git_annex "move" ["--to", "origin", ingitfile] "move of ingitfile should be no-op"
unannexed ingitfile
inmainrepo $ unannexed ingitfile
git_annex "move" ["--from", "origin", ingitfile] "move of ingitfile should be no-op"
unannexed ingitfile
inmainrepo $ unannexed ingitfile
test_move_numcopies :: Assertion
test_move_numcopies = intmpclonerepo $ do
inmainrepo $ annexed_present annexedfile
git_annex "numcopies" ["2"] "setting numcopies"
git_annex "move" ["--from", "origin", annexedfile] "move of file --from remote with numcopies unsatisfied but not made worse"
annexed_present annexedfile
inmainrepo $ annexed_notpresent annexedfile
git_annex "move" ["--to", "origin", annexedfile] "move of file --to remote with numcopies unsatisfied but not made worse"
annexed_notpresent annexedfile
inmainrepo $ annexed_present annexedfile
git_annex "get" [annexedfile] "get of file"
git_annex_shouldfail "move" ["--from", "origin", annexedfile] "move of file --from remote that violates numcopies setting not allowd"
git_annex_shouldfail "move" ["--to", "origin", annexedfile] "move of file --to remote that violates numcopies setting not allowed"
test_copy :: Assertion
test_copy = intmpclonerepo $ do
annexed_notpresent annexedfile
inmainrepo $ annexed_present annexedfile
git_annex "copy" ["--from", "origin", annexedfile] "copy --from of file"
annexed_present annexedfile
inmainrepo $ annexed_present annexedfile
git_annex "copy" ["--from", "origin", annexedfile] "copy --from of file already here"
annexed_present annexedfile
inmainrepo $ annexed_present annexedfile
git_annex "copy" ["--to", "origin", annexedfile] "copy --to of file already there"
annexed_present annexedfile
inmainrepo $ annexed_present annexedfile
git_annex "move" ["--to", "origin", annexedfile] "move --to of file already there"
annexed_notpresent annexedfile
inmainrepo $ annexed_present annexedfile
unannexed ingitfile
inmainrepo $ unannexed ingitfile
git_annex "copy" ["--to", "origin", ingitfile] "copy of ingitfile should be no-op"
unannexed ingitfile
inmainrepo $ unannexed ingitfile
git_annex "copy" ["--from", "origin", ingitfile] "copy of ingitfile should be no-op"
checkregularfile ingitfile
checkcontent ingitfile
test_preferred_content :: Assertion
test_preferred_content = intmpclonerepo $ do
annexed_notpresent annexedfile
-- get/copy --auto looks only at numcopies when preferred content is not
-- set, and with 1 copy existing, does not get the file.
git_annex "get" ["--auto", annexedfile] "get --auto of file with default preferred content"
annexed_notpresent annexedfile
git_annex "copy" ["--from", "origin", "--auto", annexedfile] "copy --auto --from of file with default preferred content"
annexed_notpresent annexedfile
git_annex "wanted" [".", "standard"] "set expression to standard"
git_annex "group" [".", "client"] "set group to standard"
git_annex "get" ["--auto", annexedfile] "get --auto of file for client"
annexed_present annexedfile
git_annex "drop" [annexedfile] "drop of file"
git_annex "copy" ["--from", "origin", "--auto", annexedfile] "copy --auto --from of file for client"
annexed_present annexedfile
git_annex "ungroup" [".", "client"] "ungroup"
git_annex "wanted" [".", "standard"] "set expression to standard"
git_annex "group" [".", "manual"] "set group to manual"
-- drop --auto with manual leaves the file where it is
git_annex "drop" ["--auto", annexedfile] "drop --auto of file with manual preferred content"
annexed_present annexedfile
git_annex "drop" [annexedfile] "drop of file"
annexed_notpresent annexedfile
-- copy/get --auto with manual does not get the file
git_annex "get" ["--auto", annexedfile] "get --auto of file with manual preferred content"
annexed_notpresent annexedfile
git_annex "copy" ["--from", "origin", "--auto", annexedfile] "copy --auto --from of file with manual preferred content"
annexed_notpresent annexedfile
git_annex "ungroup" [".", "client"] "ungroup"
git_annex "wanted" [".", "exclude=*"] "set expression to exclude=*"
git_annex "get" [annexedfile] "get of file"
annexed_present annexedfile
git_annex "drop" ["--auto", annexedfile] "drop --auto of file with exclude=*"
annexed_notpresent annexedfile
git_annex "get" ["--auto", annexedfile] "get --auto of file with exclude=*"
annexed_notpresent annexedfile
test_required_content :: Assertion
test_required_content = intmpclonerepo $ do
git_annex "get" [annexedfile] "get"
annexed_present annexedfile
git_annex "required" [".", "include=" ++ annexedfile] "annexedfile required"
git_annex_shouldfail "drop" [annexedfile] "drop of required content should fail"
annexed_present annexedfile
git_annex "drop" ["--auto", annexedfile] "drop --auto of required content skips it"
annexed_present annexedfile
writecontent annexedfiledup $ content annexedfiledup
add_annex annexedfiledup "add of second file with same content failed"
annexed_present annexedfiledup
annexed_present annexedfile
git_annex_shouldfail "drop" [annexedfiledup] "drop of file sharing required content should fail"
annexed_present annexedfiledup
annexed_present annexedfile
test_lock :: Assertion
test_lock = intmpclonerepo $ do
annexed_notpresent annexedfile
-- regression test: unlock of newly added, not committed file
-- should not fail.
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent "newfile" "foo"
git_annex "add" ["newfile"] "add new file"
git_annex "unlock" ["newfile"] "unlock on newly added, never committed file"
git_annex "get" [annexedfile] "get of file"
annexed_present annexedfile
git_annex "unlock" [annexedfile] "unlock"
unannexed annexedfile
-- write different content, to verify that lock
-- throws it away
changecontent annexedfile
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent annexedfile $ content annexedfile ++ "foo"
git_annex_shouldfail "lock" [annexedfile] "lock without --force should not be allowed"
git_annex "lock" ["--force", annexedfile] "lock --force"
-- The original content of an unlocked file is not always
-- preserved after modification, so re-get it.
git_annex "get" [annexedfile] "get of file after lock --force"
annexed_present_locked annexedfile
git_annex "unlock" [annexedfile] "unlock"
unannexed annexedfile
changecontent annexedfile
git "add" [annexedfile] "add of modified file"
runchecks [checkregularfile, checkwritable] annexedfile
c <- readFile annexedfile
assertEqual "content of modified file" c (changedcontent annexedfile)
git_annex_shouldfail "drop" [annexedfile]
"drop with no known copy of modified file should not be allowed"
lock: Fix edge cases where data loss could occur in v6 mode. In the case where the pointer file is in place, and not the content of the object, lock's performNew was called with filemodified=True, which caused it to try to repopulate the object from an unmodified associated file, of which there were none. So, the content of the object got thrown away incorrectly. This was the cause (although not the root cause) of data loss in https://github.com/datalad/datalad/issues/1020 The same problem could also occur when the work tree file is modified, but the object is not, and lock is called with --force. Added a test case for this, since it's excercising the same code path and is easier to set up than the problem above. Note that this only occurred when the keys database did not have an inode cache recorded for the annex object. Normally, the annex object would be in there, but there are of course circumstances where the inode cache is out of sync with reality, since it's only a cache. Fixed by checking if the object is unmodified; if so we don't need to try to repopulate it. This does add an additional checksum to the unlock path, but it's already checksumming the worktree file in another case, so it doesn't slow it down overall. Further investigation found a similar problem occurred when smudge --clean is called on a file and the inode cache is not populated. cleanOldKeys deleted the unmodified old object file in this case. This was also fixed by checking if the object is unmodified. In general, use of getInodeCaches and sameInodeCache is potentially dangerous if the inode cache has not gotten populated for some reason. Better to use isUnmodified. I breifly auited other places that check the inode cache, and did not see any immediate problems, but it would be easy to miss this kind of problem.
2016-10-17 16:56:26 +00:00
-- Regression test: lock --force when work tree file
-- was modified lost the (unmodified) annex object.
-- (Only occurred when the keys database was out of sync.)
test_lock_force :: Assertion
test_lock_force = intmpclonerepo $ do
git_annex "upgrade" [] "upgrade"
git_annex "get" [annexedfile] "get of file"
git_annex "unlock" [annexedfile] "unlock"
annexeval $ do
2020-07-10 18:17:35 +00:00
Just k <- Annex.WorkTree.lookupKey (toRawFilePath annexedfile)
Database.Keys.removeInodeCaches k
Database.Keys.closeDb
liftIO . removeWhenExistsWith R.removeLink
=<< Annex.fromRepo Annex.Locations.gitAnnexKeysDbIndexCache
writecontent annexedfile "test_lock_force content"
git_annex_shouldfail "lock" [annexedfile] "lock of modified file should not be allowed"
git_annex "lock" ["--force", annexedfile] "lock --force of modified file"
annexed_present_locked annexedfile
lock: Fix edge cases where data loss could occur in v6 mode. In the case where the pointer file is in place, and not the content of the object, lock's performNew was called with filemodified=True, which caused it to try to repopulate the object from an unmodified associated file, of which there were none. So, the content of the object got thrown away incorrectly. This was the cause (although not the root cause) of data loss in https://github.com/datalad/datalad/issues/1020 The same problem could also occur when the work tree file is modified, but the object is not, and lock is called with --force. Added a test case for this, since it's excercising the same code path and is easier to set up than the problem above. Note that this only occurred when the keys database did not have an inode cache recorded for the annex object. Normally, the annex object would be in there, but there are of course circumstances where the inode cache is out of sync with reality, since it's only a cache. Fixed by checking if the object is unmodified; if so we don't need to try to repopulate it. This does add an additional checksum to the unlock path, but it's already checksumming the worktree file in another case, so it doesn't slow it down overall. Further investigation found a similar problem occurred when smudge --clean is called on a file and the inode cache is not populated. cleanOldKeys deleted the unmodified old object file in this case. This was also fixed by checking if the object is unmodified. In general, use of getInodeCaches and sameInodeCache is potentially dangerous if the inode cache has not gotten populated for some reason. Better to use isUnmodified. I breifly auited other places that check the inode cache, and did not see any immediate problems, but it would be easy to miss this kind of problem.
2016-10-17 16:56:26 +00:00
test_edit :: Assertion
test_edit = test_edit' False
test_edit_precommit :: Assertion
test_edit_precommit = test_edit' True
test_edit' :: Bool -> Assertion
test_edit' precommit = intmpclonerepo $ do
git_annex "get" [annexedfile] "get of file"
2012-11-11 04:51:07 +00:00
annexed_present annexedfile
git_annex "edit" [annexedfile] "edit"
2012-11-11 04:51:07 +00:00
unannexed annexedfile
changecontent annexedfile
git "add" [annexedfile] "git add of edited file"
2012-11-11 04:51:07 +00:00
if precommit
then git_annex "pre-commit" [] "pre-commit"
else git "commit" ["-q", "-m", "contentchanged"] "git commit of edited file"
runchecks [checkregularfile, checkwritable] annexedfile
2012-11-11 04:51:07 +00:00
c <- readFile annexedfile
assertEqual "content of modified file" c (changedcontent annexedfile)
git_annex_shouldfail "drop" [annexedfile] "drop no known copy of modified file should not be allowed"
test_partial_commit :: Assertion
test_partial_commit = intmpclonerepo $ do
git_annex "get" [annexedfile] "get of file"
annexed_present annexedfile
git_annex "unlock" [annexedfile] "unlock"
changecontent annexedfile
git "commit" ["-q", "-m", "test", annexedfile]
"partial commit of unlocked file should be allowed"
test_fix :: Assertion
test_fix = intmpclonerepo $ unlessM (hasUnlockedFiles <$> getTestMode) $ do
2011-01-07 18:08:43 +00:00
annexed_notpresent annexedfile
git_annex "fix" [annexedfile] "fix of not present"
2011-01-07 18:08:43 +00:00
annexed_notpresent annexedfile
git_annex "get" [annexedfile] "get of file"
annexed_present annexedfile
git_annex "fix" [annexedfile] "fix of present file"
2011-01-07 18:08:43 +00:00
annexed_present annexedfile
createDirectory subdir
git "mv" [annexedfile, subdir] "git mv"
git_annex "fix" [newfile] "fix of moved file"
runchecks [checklink, checkunwritable] newfile
c <- readFile newfile
assertEqual "content of moved file" c (content annexedfile)
2012-11-11 04:51:07 +00:00
where
subdir = "s"
newfile = subdir ++ "/" ++ annexedfile
2011-01-07 01:39:26 +00:00
test_trust :: Assertion
test_trust = intmpclonerepo $ do
git_annex "trust" ["--force", repo] "trust"
2011-10-15 20:21:08 +00:00
trustcheck Logs.Trust.Trusted "trusted 1"
git_annex "trust" ["--force", repo] "trust of trusted"
2011-10-15 20:21:08 +00:00
trustcheck Logs.Trust.Trusted "trusted 2"
git_annex "untrust" [repo] "untrust"
2011-10-15 20:21:08 +00:00
trustcheck Logs.Trust.UnTrusted "untrusted 1"
git_annex "untrust" [repo] "untrust of untrusted"
2011-10-15 20:21:08 +00:00
trustcheck Logs.Trust.UnTrusted "untrusted 2"
git_annex "dead" [repo] "dead"
trustcheck Logs.Trust.DeadTrusted "deadtrusted 1"
git_annex "dead" [repo] "dead of dead"
trustcheck Logs.Trust.DeadTrusted "deadtrusted 2"
git_annex "semitrust" [repo] "semitrust"
2011-10-15 20:21:08 +00:00
trustcheck Logs.Trust.SemiTrusted "semitrusted 1"
git_annex "semitrust" [repo] "semitrust of semitrusted"
2011-10-15 20:21:08 +00:00
trustcheck Logs.Trust.SemiTrusted "semitrusted 2"
2012-11-11 04:51:07 +00:00
where
repo = "origin"
trustcheck expected msg = do
present <- annexeval $ do
l <- Logs.Trust.trustGet expected
u <- Remote.nameToUUID repo
return $ u `elem` l
assertBool msg present
2011-01-11 22:50:18 +00:00
test_fsck_basic :: Assertion
test_fsck_basic = intmpclonerepo $ do
git_annex "fsck" [] "fsck"
git_annex "numcopies" ["2"] "numcopies config"
fsck_should_fail "numcopies unsatisfied"
git_annex "numcopies" ["1"] "numcopies config"
2013-11-15 00:09:47 +00:00
corrupt annexedfile
corrupt sha1annexedfile
2012-11-11 04:51:07 +00:00
where
corrupt f = do
git_annex "get" [f] "get of file"
Utility.FileMode.allowWrite (toRawFilePath f)
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent f (changedcontent f)
ifM (hasUnlockedFiles <$> getTestMode)
( git_annex "fsck" []"fsck on unlocked file with changed file content"
, git_annex_shouldfail "fsck" [] "fsck with corrupted file content should error"
)
git_annex "fsck" [] "second fsck, after first fsck should have fixed problem"
test_fsck_bare :: Assertion
test_fsck_bare = intmpbareclonerepo $
git_annex "fsck" [] "fsck"
test_fsck_localuntrusted :: Assertion
test_fsck_localuntrusted = intmpclonerepo $ do
git_annex "get" [annexedfile] "get"
git_annex "untrust" ["origin"] "untrust of origin repo"
git_annex "untrust" ["."] "untrust of current repo"
fsck_should_fail "content only available in untrusted (current) repository"
git_annex "trust" ["--force", "."] "trust of current repo"
git_annex "fsck" [annexedfile] "fsck on file present in trusted repo"
test_fsck_remoteuntrusted :: Assertion
test_fsck_remoteuntrusted = intmpclonerepo $ do
git_annex "numcopies" ["2"] "numcopies config"
git_annex "get" [annexedfile] "get"
git_annex "get" [sha1annexedfile] "get"
git_annex "fsck" [] "fsck with numcopies=2 and 2 copies"
git_annex "untrust" ["origin"] "untrust of origin"
fsck_should_fail "content not replicated to enough non-untrusted repositories"
test_fsck_fromremote :: Assertion
test_fsck_fromremote = intmpclonerepo $ do
git_annex "fsck" ["--from", "origin"] "fsck --from origin"
fsck_should_fail :: String -> Assertion
fsck_should_fail m = git_annex_shouldfail "fsck" []
("fsck should not succeed with " ++ m)
-- Make sure that the "converting git to annexed" recipe in
-- doc/tips/largefiles.mdwn continues to work.
test_conversion_git_to_annexed :: Assertion
test_conversion_git_to_annexed = intmpclonerepo $ do
git "rm" ["--cached", ingitfile] "git rm --cached"
git_annex "add" ["--force-large", ingitfile] "add --force-large"
git "commit" ["-q", "-m", "commit", ingitfile] "git commit"
whenM (unlockedFiles <$> getTestMode) $
git_annex "unlock" [ingitfile] "unlock"
annexed_present ingitfile
-- Make sure that the "converting annexed to git" recipe in
-- doc/tips/largefiles.mdwn continues to work.
test_conversion_annexed_to_git :: Assertion
test_conversion_annexed_to_git = intmpclonerepo $ do
git_annex "get" [annexedfile] "get"
git_annex "unlock" [annexedfile] "unlock"
git "rm" ["--cached", annexedfile] "git rm --cached"
git_annex "add" ["--force-small", annexedfile] "add --force-small"
git "commit" ["-q", "-m", "commit", annexedfile] "git commit"
unannexed_in_git annexedfile
test_migrate :: Assertion
test_migrate = test_migrate' False
test_migrate_via_gitattributes :: Assertion
test_migrate_via_gitattributes = test_migrate' True
test_migrate' :: Bool -> Assertion
test_migrate' usegitattributes = intmpclonerepo $ do
2012-11-11 04:51:07 +00:00
annexed_notpresent annexedfile
annexed_notpresent sha1annexedfile
git_annex "migrate" [annexedfile] "migrate of not present"
git_annex "migrate" [sha1annexedfile] "migrate of not present"
git_annex "get" [annexedfile] "get of file"
git_annex "get" [sha1annexedfile] "get of file"
2012-11-11 04:51:07 +00:00
annexed_present annexedfile
annexed_present sha1annexedfile
if usegitattributes
then do
2014-02-11 05:35:11 +00:00
writeFile ".gitattributes" "* annex.backend=SHA1"
git_annex "migrate" [sha1annexedfile]
"migrate sha1annexedfile"
git_annex "migrate" [annexedfile]
"migrate annexedfile"
2012-11-11 04:51:07 +00:00
else do
git_annex "migrate" [sha1annexedfile, "--backend", "SHA1"]
"migrate sha1annexedfile"
git_annex "migrate" [annexedfile, "--backend", "SHA1"]
"migrate annexedfile"
2012-11-11 04:51:07 +00:00
annexed_present annexedfile
annexed_present sha1annexedfile
checkbackend annexedfile backendSHA1
checkbackend sha1annexedfile backendSHA1
-- check that reversing a migration works
2014-02-11 05:35:11 +00:00
writeFile ".gitattributes" "* annex.backend=SHA256"
git_annex "migrate" [sha1annexedfile] "migrate sha1annexedfile"
git_annex "migrate" [annexedfile] "migrate annexedfile"
2012-11-11 04:51:07 +00:00
annexed_present annexedfile
annexed_present sha1annexedfile
checkbackend annexedfile backendSHA256
checkbackend sha1annexedfile backendSHA256
2011-01-12 01:11:32 +00:00
test_unused :: Assertion
test_unused = intmpclonerepo $ do
checkunused [] "in new clone"
git_annex "get" [annexedfile] "get of file"
git_annex "get" [sha1annexedfile] "get of file"
annexedfilekey <- getKey backendSHA256E annexedfile
sha1annexedfilekey <- getKey backendSHA1 sha1annexedfile
checkunused [] "after get"
git "rm" ["-fq", annexedfile] "git rm"
checkunused [] "after rm"
-- commit the rm, and when on an adjusted branch, sync it back to
-- the master branch
git_annex "sync" ["--no-push", "--no-pull"] "git-annex sync"
checkunused [] "after commit"
2011-09-28 21:48:11 +00:00
-- unused checks origin/master; once it's gone it is really unused
git "remote" ["rm", "origin"] "git remote rm origin"
checkunused [annexedfilekey] "after origin branches are gone"
git "rm" ["-fq", sha1annexedfile] "git rm"
git_annex "sync" ["--no-push", "--no-pull"] "git-annex sync"
checkunused [annexedfilekey, sha1annexedfilekey] "after rm sha1annexedfile"
2011-01-12 05:58:23 +00:00
-- good opportunity to test dropkey also
git_annex "dropkey" ["--force", Key.serializeKey annexedfilekey] "dropkey"
checkunused [sha1annexedfilekey] ("after dropkey --force " ++ Key.serializeKey annexedfilekey)
2011-01-12 05:58:23 +00:00
git_annex_shouldfail "dropunused" ["1"] "dropunused should not be allowed without --force"
git_annex "dropunused" ["--force", "1"] "dropunused"
checkunused [] "after dropunused"
git_annex_shouldfail "dropunused" ["--force", "10", "501"] "dropunused on bogus numbers"
2011-01-12 05:58:23 +00:00
2016-02-16 20:02:54 +00:00
-- Unused used to miss renamed symlinks that were not staged
-- and pointed at annexed content, and think that content was unused.
-- This is only relevant when using locked files; if the file is
-- unlocked, the work tree file has the content, and there's no way
-- to associate it with the key.
unlessM (hasUnlockedFiles <$> getTestMode) $ do
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent "unusedfile" "unusedcontent"
git_annex "add" ["unusedfile"] "add of unusedfile"
2016-02-16 20:02:54 +00:00
unusedfilekey <- getKey backendSHA256E "unusedfile"
renameFile "unusedfile" "unusedunstagedfile"
git "rm" ["-qf", "unusedfile"] "git rm"
2016-02-16 20:02:54 +00:00
checkunused [] "with unstaged link"
removeFile "unusedunstagedfile"
checkunused [unusedfilekey] "with renamed link deleted"
-- unused used to miss symlinks that were deleted or modified
-- manually
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent "unusedfile" "unusedcontent"
git_annex "add" ["unusedfile"] "add of unusedfile"
git "add" ["unusedfile"] "git add"
unusedfilekey' <- getKey backendSHA256E "unusedfile"
checkunused [] "with staged deleted link"
git "rm" ["-qf", "unusedfile"] "git rm"
checkunused [unusedfilekey'] "with staged link deleted"
-- unused used to false positive on symlinks that were
-- deleted or modified manually, but not staged as such
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent "unusedfile" "unusedcontent"
git_annex "add" ["unusedfile"] "add of unusedfile"
git "add" ["unusedfile"] "git add"
checkunused [] "with staged file"
removeFile "unusedfile"
checkunused [] "with staged deleted file"
-- When an unlocked file is modified, git diff will cause git-annex
-- to add its content to the repository. Make sure that's not
-- found as unused.
whenM (hasUnlockedFiles <$> getTestMode) $ do
let f = "unlockedfile"
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent f "unlockedcontent1"
git "add" ["unlockedfile"] "git add"
checkunused [] "with unlocked file before modification"
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent f "unlockedcontent2"
checkunused [] "with unlocked file after modification"
git_shouldfail "diff" ["--quiet", f] "git diff should exit nonzero when unlocked file is modified"
-- still nothing unused because one version is in the index
-- and the other is in the work tree
checkunused [] "with unlocked file after git diff"
2012-11-11 04:51:07 +00:00
where
checkunused expectedkeys desc = do
git_annex "unused" [] "unused"
unusedmap <- annexeval $ Logs.Unused.readUnusedMap mempty
2012-11-11 04:51:07 +00:00
let unusedkeys = M.elems unusedmap
assertEqual ("unused keys differ " ++ desc)
(sort expectedkeys) (sort unusedkeys)
2011-01-12 05:58:23 +00:00
test_describe :: Assertion
test_describe = intmpclonerepo $ do
git_annex "describe" [".", "this repo"] "describe 1"
git_annex "describe" ["origin", "origin repo"] "describe 2"
test_find :: Assertion
test_find = intmpclonerepo $ do
annexed_notpresent annexedfile
git_annex_expectoutput "find" [] []
git_annex "get" [annexedfile] "get"
2011-12-21 06:32:40 +00:00
annexed_present annexedfile
annexed_notpresent sha1annexedfile
git_annex_expectoutput "find" [] [annexedfile]
git_annex_expectoutput "find" ["--exclude", annexedfile, "--and", "--exclude", sha1annexedfile] []
git_annex_expectoutput "find" ["--include", annexedfile] [annexedfile]
git_annex_expectoutput "find" ["--not", "--in", "origin"] []
git_annex_expectoutput "find" ["--copies", "1", "--and", "--not", "--copies", "2"] [sha1annexedfile]
git_annex_expectoutput "find" ["--inbackend", "SHA1"] [sha1annexedfile]
git_annex_expectoutput "find" ["--inbackend", "WORM"] []
{- --include=* should match files in subdirectories too,
- and --exclude=* should exclude them. -}
createDirectory "dir"
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent "dir/subfile" "subfile"
git_annex "add" ["dir"] "add of subdir"
git_annex_expectoutput "find" ["--include", "*", "--exclude", annexedfile, "--exclude", sha1annexedfile] ["dir/subfile"]
git_annex_expectoutput "find" ["--exclude", "*"] []
test_merge :: Assertion
test_merge = intmpclonerepo $
git_annex "merge" [] "merge"
test_info :: Assertion
test_info = intmpclonerepo $ do
json <- BU8.fromString <$> git_annex_output "info" ["--json"]
case Utility.Aeson.eitherDecode json :: Either String Utility.Aeson.Value of
Right _ -> return ()
Left e -> assertFailure e
test_version :: Assertion
test_version = intmpclonerepo $
git_annex "version" [] "version"
test_sync :: Assertion
test_sync = intmpclonerepo $ do
git_annex "sync" [] "sync"
{- Regression test for bug fixed in
- 039e83ed5d1a11fd562cce55b8429c840d72443e, where a present
- wanted file was dropped. -}
git_annex "get" [annexedfile] "get"
git_annex_expectoutput "find" ["--in", "."] [annexedfile]
git_annex "wanted" [".", "present"] "wanted"
git_annex "sync" ["--content"] "sync"
git_annex_expectoutput "find" ["--in", "."] [annexedfile]
git_annex "drop" [annexedfile] "drop"
git_annex_expectoutput "find" ["--in", "."] []
git_annex "sync" ["--content"] "sync"
git_annex_expectoutput "find" ["--in", "."] []
2019-11-14 18:02:09 +00:00
{- Regression test for the concurrency bug fixed in
- 667d38a8f11c1ee8f256cdbd80e225c2bae06595 -}
test_concurrent_get_of_dup_key_regression :: Assertion
test_concurrent_get_of_dup_key_regression = intmpclonerepo $ do
makedup dupfile
-- This was sufficient currency to trigger the bug.
git_annex "get" ["-J1", annexedfile, dupfile]
"concurrent get -J1 with dup"
2019-11-14 18:02:09 +00:00
git_annex "drop" ["-J1"]
"drop with dup"
2019-11-14 18:02:09 +00:00
-- With -J2, one more dup file was needed to trigger the bug.
makedup dupfile2
git_annex "get" ["-J2", annexedfile, dupfile, dupfile2]
"concurrent get -J2 with dup"
2019-11-14 18:02:09 +00:00
git_annex "drop" ["-J2"]
"drop with dup"
2019-11-14 18:02:09 +00:00
where
dupfile = annexedfile ++ "2"
dupfile2 = annexedfile ++ "3"
makedup f = do
Utility.CopyFile.copyFileExternal Utility.CopyFile.CopyAllMetaData annexedfile f
@? "copying annexed file failed"
git "add" [f] "git add"
2019-11-14 18:02:09 +00:00
{- Regression test for union merge bug fixed in
- 0214e0fb175a608a49b812d81b4632c081f63027 -}
test_union_merge_regression :: Assertion
test_union_merge_regression =
{- We need 3 repos to see this bug. -}
withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 ->
withtmpclonerepo $ \r3 -> do
forM_ [r1, r2, r3] $ \r -> indir r $ do
when (r /= r1) $
git "remote" ["add", "r1", "../../" ++ r1] "remote add"
when (r /= r2) $
git "remote" ["add", "r2", "../../" ++ r2] "remote add"
when (r /= r3) $
git "remote" ["add", "r3", "../../" ++ r3] "remote add"
git_annex "get" [annexedfile] "get"
git "remote" ["rm", "origin"] "remote rm"
forM_ [r3, r2, r1] $ \r -> indir r $
git_annex "sync" [] ("sync in " ++ r)
forM_ [r3, r2] $ \r -> indir r $
git_annex "drop" ["--force", annexedfile] ("drop in " ++ r)
indir r1 $ do
git_annex "sync" [] "sync in r1"
git_annex_expectoutput "find" ["--in", "r3"] []
{- This was the bug. The sync
- mangled location log data and it
- thought the file was still in r2 -}
git_annex_expectoutput "find" ["--in", "r2"] []
{- Regression test for the automatic conflict resolution bug fixed
- in f4ba19f2b8a76a1676da7bb5850baa40d9c388e2. -}
test_conflict_resolution_movein_regression :: Assertion
test_conflict_resolution_movein_regression = withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 -> do
let rname r = if r == r1 then "r1" else "r2"
forM_ [r1, r2] $ \r -> indir r $ do
{- Get all files, see check below. -}
git_annex "get" [] "get"
disconnectOrigin
pair r1 r2
forM_ [r1, r2] $ \r -> indir r $ do
{- Set up a conflict. -}
let newcontent = content annexedfile ++ rname r
git_annex "unlock" [annexedfile] "unlock"
writecontent annexedfile newcontent
{- Sync twice in r1 so it gets the conflict resolution
- update from r2 -}
forM_ [r1, r2, r1] $ \r -> indir r $
git_annex "sync" ["--force"] ("sync in " ++ rname r)
{- After the sync, it should be possible to get all
- files. This includes both sides of the conflict,
- although the filenames are not easily predictable.
-
- The bug caused one repo to be missing the content
- of the file that had been put in it. -}
forM_ [r1, r2] $ \r -> indir r $ do
git_annex "get" [] ("get all files after merge conflict resolution in " ++ rname r)
2014-03-05 03:12:15 +00:00
{- Simple case of conflict resolution; 2 different versions of annexed
- file. -}
test_conflict_resolution :: Assertion
test_conflict_resolution =
withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 -> do
indir r1 $ do
2014-03-05 03:12:15 +00:00
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor1"
add_annex conflictor "add conflicter"
git_annex "sync" [] "sync in r1"
indir r2 $ do
2014-03-05 03:12:15 +00:00
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor2"
add_annex conflictor "add conflicter"
git_annex "sync" [] "sync in r2"
pair r1 r2
forM_ [r1,r2,r1] $ \r -> indir r $
git_annex "sync" [] "sync"
2014-03-05 03:12:15 +00:00
checkmerge "r1" r1
checkmerge "r2" r2
where
conflictor = "conflictor"
variantprefix = conflictor ++ ".variant"
checkmerge what d = do
l <- getDirectoryContents d
let v = filter (variantprefix `isPrefixOf`) l
length v == 2
@? (what ++ " not exactly 2 variant files in: " ++ show l)
conflictor `notElem` l @? ("conflictor still present after conflict resolution")
indir d $ do
git_annex "get" v "get"
git_annex_expectoutput "find" v v
2014-03-05 03:12:15 +00:00
{- Conflict resolution while in an adjusted branch. -}
test_conflict_resolution_adjusted_branch :: Assertion
test_conflict_resolution_adjusted_branch =
withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 -> whenM (adjustedbranchsupported r2) $ do
indir r1 $ do
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor1"
add_annex conflictor "add conflicter"
git_annex "sync" [] "sync in r1"
indir r2 $ do
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor2"
add_annex conflictor "add conflicter"
git_annex "sync" [] "sync in r2"
-- We might be in an adjusted branch
-- already, when eg on a crippled
-- filesystem. So, --force it.
git_annex "adjust" ["--unlock", "--force"] "adjust"
pair r1 r2
forM_ [r1,r2,r1] $ \r -> indir r $
git_annex "sync" [] "sync"
checkmerge "r1" r1
checkmerge "r2" r2
where
conflictor = "conflictor"
variantprefix = conflictor ++ ".variant"
checkmerge what d = do
l <- getDirectoryContents d
let v = filter (variantprefix `isPrefixOf`) l
length v == 2
@? (what ++ " not exactly 2 variant files in: " ++ show l)
conflictor `notElem` l @? ("conflictor still present after conflict resolution")
indir d $ do
git_annex "get" v "get"
git_annex_expectoutput "find" v v
2014-03-05 03:12:15 +00:00
{- Check merge conflict resolution when one side is an annexed
- file, and the other is a directory. -}
test_mixed_conflict_resolution :: Assertion
test_mixed_conflict_resolution = do
check True
check False
where
check inr1 = withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 -> do
indir r1 $ do
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor"
add_annex conflictor "add conflicter"
git_annex "sync" [] "sync in r1"
indir r2 $ do
disconnectOrigin
createDirectory conflictor
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent subfile "subfile"
add_annex conflictor "add conflicter"
git_annex "sync" [] "sync in r2"
pair r1 r2
let l = if inr1 then [r1, r2] else [r2, r1]
forM_ l $ \r -> indir r $
git_annex "sync" [] "sync in mixed conflict"
checkmerge "r1" r1
checkmerge "r2" r2
2014-02-04 19:14:16 +00:00
conflictor = "conflictor"
subfile = conflictor </> "subfile"
2014-02-04 19:14:16 +00:00
variantprefix = conflictor ++ ".variant"
checkmerge what d = do
doesDirectoryExist (d </> conflictor)
@? (d ++ " conflictor directory missing")
2014-02-04 19:14:16 +00:00
l <- getDirectoryContents d
let v = filter (variantprefix `isPrefixOf`) l
not (null v)
2014-03-05 03:12:15 +00:00
@? (what ++ " conflictor variant file missing in: " ++ show l )
length v == 1
@? (what ++ " too many variant files in: " ++ show v)
indir d $ do
git_annex "get" (conflictor:v) ("get in " ++ what)
git_annex_expectoutput "find" [conflictor] [fromRawFilePath (Git.FilePath.toInternalGitPath (toRawFilePath subfile))]
git_annex_expectoutput "find" v v
2014-02-04 19:14:16 +00:00
{- Check merge conflict resolution when both repos start with an annexed
- file; one modifies it, and the other deletes it. -}
test_remove_conflict_resolution :: Assertion
test_remove_conflict_resolution = do
check True
check False
where
check inr1 = withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 -> do
indir r1 $ do
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor"
add_annex conflictor "add conflicter"
git_annex "sync" [] "sync in r1"
indir r2 $
disconnectOrigin
pair r1 r2
indir r2 $ do
git_annex "sync" [] "sync in r2"
git_annex "get" [conflictor] "get conflictor"
git_annex "unlock" [conflictor] "unlock conflictor"
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "newconflictor"
indir r1 $
removeWhenExistsWith R.removeLink (toRawFilePath conflictor)
let l = if inr1 then [r1, r2, r1] else [r2, r1, r2]
forM_ l $ \r -> indir r $
git_annex "sync" [] "sync"
checkmerge "r1" r1
checkmerge "r2" r2
conflictor = "conflictor"
variantprefix = conflictor ++ ".variant"
checkmerge what d = do
l <- getDirectoryContents d
let v = filter (variantprefix `isPrefixOf`) l
not (null v)
2014-03-05 03:12:15 +00:00
@? (what ++ " conflictor variant file missing in: " ++ show l )
length v == 1
@? (what ++ " too many variant files in: " ++ show v)
{- Check merge confalict resolution when a file is annexed in one repo,
- and checked directly into git in the other repo.
-}
test_nonannexed_file_conflict_resolution :: Assertion
test_nonannexed_file_conflict_resolution = do
check True
check False
where
check inr1 = withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 -> do
indir r1 $ do
disconnectOrigin
writecontent conflictor "conflictor"
add_annex conflictor "add conflicter"
git_annex "sync" [] "sync in r1"
indir r2 $ do
disconnectOrigin
writecontent conflictor nonannexed_content
git "config"
[ "annex.largefiles"
, "exclude=" ++ ingitfile ++ " and exclude=" ++ conflictor
] "git config annex.largefiles"
git "add" [conflictor] "git add conflictor"
git_annex "sync" [] "sync in r2"
pair r1 r2
let l = if inr1 then [r1, r2] else [r2, r1]
forM_ l $ \r -> indir r $
git_annex "sync" [] "sync"
checkmerge "r1" r1
checkmerge "r2" r2
conflictor = "conflictor"
nonannexed_content = "nonannexed"
variantprefix = conflictor ++ ".variant"
checkmerge what d = do
l <- getDirectoryContents d
let v = filter (variantprefix `isPrefixOf`) l
not (null v)
@? (what ++ " conflictor variant file missing in: " ++ show l )
2014-03-05 03:12:15 +00:00
length v == 1
@? (what ++ " too many variant files in: " ++ show v)
conflictor `elem` l @? (what ++ " conflictor file missing in: " ++ show l)
s <- catchMaybeIO (readFile (d </> conflictor))
s == Just nonannexed_content
@? (what ++ " wrong content for nonannexed file: " ++ show s)
{- Check merge conflict resolution when a file is annexed in one repo,
- and is a non-git-annex symlink in the other repo.
-
- Test can only run when coreSymlinks is supported, because git needs to
- be able to check out the non-git-annex symlink.
-}
test_nonannexed_symlink_conflict_resolution :: Assertion
test_nonannexed_symlink_conflict_resolution = do
check True
check False
where
check inr1 = withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 ->
whenM (checkRepo (Types.coreSymlinks <$> Annex.getGitConfig) r1) $ do
indir r1 $ do
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor"
add_annex conflictor "add conflicter"
git_annex "sync" [] "sync in r1"
indir r2 $ do
disconnectOrigin
createSymbolicLink symlinktarget "conflictor"
git "add" [conflictor] "git add conflictor"
git_annex "sync" [] "sync in r2"
pair r1 r2
let l = if inr1 then [r1, r2] else [r2, r1]
forM_ l $ \r -> indir r $
git_annex "sync" [] "sync"
checkmerge "r1" r1
checkmerge "r2" r2
conflictor = "conflictor"
symlinktarget = "dummy-target"
variantprefix = conflictor ++ ".variant"
checkmerge what d = do
l <- getDirectoryContents d
let v = filter (variantprefix `isPrefixOf`) l
not (null v)
@? (what ++ " conflictor variant file missing in: " ++ show l )
length v == 1
@? (what ++ " too many variant files in: " ++ show v)
conflictor `elem` l @? (what ++ " conflictor file missing in: " ++ show l)
s <- catchMaybeIO (readSymbolicLink (d </> conflictor))
s == Just symlinktarget
@? (what ++ " wrong target for nonannexed symlink: " ++ show s)
{- Check merge conflict resolution when there is a local file,
- that is not staged or committed, that conflicts with what's being added
- from the remmote.
-
- Case 1: Remote adds file named conflictor; local has a file named
- conflictor.
-
- Case 2: Remote adds conflictor/file; local has a file named conflictor.
-}
test_uncommitted_conflict_resolution :: Assertion
test_uncommitted_conflict_resolution = do
check conflictor
check (conflictor </> "file")
where
check remoteconflictor = withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 -> do
indir r1 $ do
disconnectOrigin
createDirectoryIfMissing True (fromRawFilePath (parentDir (toRawFilePath remoteconflictor)))
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent remoteconflictor annexedcontent
add_annex conflictor "add remoteconflicter"
git_annex "sync" [] "sync in r1"
indir r2 $ do
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor localcontent
pair r1 r2
-- this case is intentionally not handled
-- since the user can recover on their own easily
indir r2 $ git_annex_shouldfail "sync" [] "sync should not succeed"
conflictor = "conflictor"
localcontent = "local"
annexedcontent = "annexed"
{- On Windows/FAT, repeated conflict resolution sometimes
- lost track of whether a file was a symlink.
-}
test_conflict_resolution_symlink_bit :: Assertion
test_conflict_resolution_symlink_bit = unlessM (hasUnlockedFiles <$> getTestMode) $
withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 ->
withtmpclonerepo $ \r3 -> do
indir r1 $ do
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor"
git_annex "add" [conflictor] "add conflicter"
git_annex "sync" [] "sync in r1"
check_is_link conflictor "r1"
indir r2 $ do
createDirectory conflictor
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent (conflictor </> "subfile") "subfile"
git_annex "add" [conflictor] "add conflicter"
git_annex "sync" [] "sync in r2"
check_is_link (conflictor </> "subfile") "r2"
indir r3 $ do
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor"
git_annex "add" [conflictor] "add conflicter"
git_annex "sync" [] "sync in r1"
check_is_link (conflictor </> "subfile") "r3"
where
2014-02-04 19:14:16 +00:00
conflictor = "conflictor"
check_is_link f what = do
git_annex_expectoutput "find" ["--include=*", f] [fromRawFilePath (Git.FilePath.toInternalGitPath (toRawFilePath f))]
l <- annexeval $ Annex.inRepo $ Git.LsTree.lsTreeFiles (Git.LsTree.LsTreeLong False) Git.Ref.headRef [f]
all (\i -> Git.Types.toTreeItemType (Git.LsTree.mode i) == Just Git.Types.TreeSymlink) l
@? (what ++ " " ++ f ++ " lost symlink bit after merge: " ++ show l)
{- An unlocked file that conflicts with a locked file should be resolved
- in favor of the unlocked file, with no variant files, as long as they
- both point to the same key. -}
test_mixed_lock_conflict_resolution :: Assertion
test_mixed_lock_conflict_resolution =
withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 -> do
indir r1 $ do
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor"
git_annex "add" [conflictor] "add conflicter"
git_annex "sync" [] "sync in r1"
indir r2 $ do
disconnectOrigin
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor"
git_annex "add" [conflictor] "add conflicter"
git_annex "unlock" [conflictor] "unlock conflicter"
git_annex "sync" [] "sync in r2"
pair r1 r2
forM_ [r1,r2,r1] $ \r -> indir r $
git_annex "sync" [] "sync"
checkmerge "r1" r1
checkmerge "r2" r2
where
conflictor = "conflictor"
variantprefix = conflictor ++ ".variant"
checkmerge what d = indir d $ do
l <- getDirectoryContents "."
let v = filter (variantprefix `isPrefixOf`) l
length v == 0
@? (what ++ " not exactly 0 variant files in: " ++ show l)
conflictor `elem` l @? ("conflictor not present after conflict resolution")
git_annex "get" [conflictor] "get"
git_annex_expectoutput "find" [conflictor] [conflictor]
-- regular file because it's unlocked
checkregularfile conflictor
{- Regression test for a bad merge between two adjusted branch repos,
- where the same file is added to both independently. The bad merge
- emptied the whole tree. -}
test_adjusted_branch_merge_regression :: Assertion
test_adjusted_branch_merge_regression = do
withtmpclonerepo $ \r1 ->
withtmpclonerepo $ \r2 -> whenM (adjustedbranchsupported r1) $ do
pair r1 r2
setup r1
setup r2
checkmerge "r1" r1
checkmerge "r2" r2
where
conflictor = "conflictor"
2018-12-19 17:36:14 +00:00
setup r = indir r $ whensupported $ do
disconnectOrigin
git_annex "upgrade" [] "upgrade"
git_annex "adjust" ["--unlock", "--force"] "adjust"
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent conflictor "conflictor"
git_annex "add" [conflictor] "add conflicter"
git_annex "sync" [] "sync"
2018-12-19 17:36:14 +00:00
checkmerge what d = indir d $ whensupported $ do
git_annex "sync" [] ("sync should not work in " ++ what)
l <- getDirectoryContents "."
conflictor `elem` l
@? ("conflictor not present after merge in " ++ what)
2018-12-19 17:36:14 +00:00
-- Currently this fails on FAT, for unknown reasons not to
-- do with what it's intended to test.
whensupported = unlessM (annexeval Config.crippledFileSystem)
{- Regression test for a bug in adjusted branch syncing code, where adding
- a subtree to an existing tree lost files. -}
test_adjusted_branch_subtree_regression :: Assertion
test_adjusted_branch_subtree_regression =
withtmpclonerepo $ \r -> whenM (adjustedbranchsupported r) $ do
indir r $ do
disconnectOrigin
origbranch <- annexeval origBranch
git_annex "upgrade" [] "upgrade"
git_annex "adjust" ["--unlock", "--force"] "adjust"
createDirectoryIfMissing True "a/b/c"
writecontent "a/b/c/d" "foo"
git_annex "add" ["a/b/c"] "add a/b/c"
git_annex "sync" [] "sync"
createDirectoryIfMissing True "a/b/x"
writecontent "a/b/x/y" "foo"
git_annex "add" ["a/b/x"] "add a/b/x"
git_annex "sync" [] "sync"
git "checkout" [origbranch] "git checkout"
doesFileExist "a/b/x/y" @? ("a/b/x/y missing from master after adjusted branch sync")
{- Set up repos as remotes of each other. -}
pair :: FilePath -> FilePath -> Assertion
pair r1 r2 = forM_ [r1, r2] $ \r -> indir r $ do
when (r /= r1) $
git "remote" ["add", "r1", "../../" ++ r1] "remote add"
when (r /= r2) $
git "remote" ["add", "r2", "../../" ++ r2] "remote add"
test_map :: Assertion
test_map = intmpclonerepo $ do
-- set descriptions, that will be looked for in the map
git_annex "describe" [".", "this repo"] "describe 1"
git_annex "describe" ["origin", "origin repo"] "describe 2"
-- --fast avoids it running graphviz, not a build dependency
git_annex "map" ["--fast"] "map"
test_uninit :: Assertion
test_uninit = intmpclonerepo $ do
git_annex "get" [] "get"
annexed_present annexedfile
-- any exit status is accepted; does abnormal exit
git_annex' (const True) "uninit" [] "uninit"
checkregularfile annexedfile
doesDirectoryExist ".git" @? ".git vanished in uninit"
test_uninit_inbranch :: Assertion
test_uninit_inbranch = intmpclonerepo $ do
git "checkout" ["git-annex"] "git checkout git-annex"
git_annex_shouldfail "uninit" [] "uninit should not succeed when git-annex branch is checked out"
test_upgrade :: Assertion
test_upgrade = intmpclonerepo $
git_annex "upgrade" [] "upgrade"
test_whereis :: Assertion
test_whereis = intmpclonerepo $ do
annexed_notpresent annexedfile
git_annex "whereis" [annexedfile] "whereis on non-present file"
git_annex "untrust" ["origin"] "untrust"
git_annex_shouldfail "whereis" [annexedfile] "whereis should exit nonzero on non-present file only present in untrusted repo"
git_annex "get" [annexedfile] "get"
annexed_present annexedfile
git_annex "whereis" [annexedfile] "whereis on present file"
test_hook_remote :: Assertion
test_hook_remote = intmpclonerepo $ do
2013-08-04 17:07:55 +00:00
#ifndef mingw32_HOST_OS
git_annex "initremote" (words "foo type=hook encryption=none hooktype=foo") "initremote"
createDirectory dir
git_config "annex.foo-store-hook" $
"cp $ANNEX_FILE " ++ loc
git_config "annex.foo-retrieve-hook" $
"cp " ++ loc ++ " $ANNEX_FILE"
git_config "annex.foo-remove-hook" $
"rm -f " ++ loc
git_config "annex.foo-checkpresent-hook" $
"if [ -e " ++ loc ++ " ]; then echo $ANNEX_KEY; fi"
git_annex "get" [annexedfile] "get of file"
annexed_present annexedfile
git_annex "copy" [annexedfile, "--to", "foo"] "copy --to hook remote"
annexed_present annexedfile
git_annex "drop" [annexedfile, "--numcopies=2"] "drop"
annexed_notpresent annexedfile
git_annex "move" [annexedfile, "--from", "foo"] "move --from hook remote"
annexed_present annexedfile
git_annex_shouldfail "drop" [annexedfile, "--numcopies=2"] "drop should not be allowed with numcopies=2"
annexed_present annexedfile
2012-11-11 04:51:07 +00:00
where
dir = "dir"
loc = dir ++ "/$ANNEX_KEY"
git_config k v = git "config" [k, v] "git config"
#else
-- this test doesn't work in Windows TODO
noop
#endif
test_directory_remote :: Assertion
test_directory_remote = intmpclonerepo $ do
createDirectory "dir"
git_annex "initremote" (words "foo type=directory encryption=none directory=dir") "initremote"
git_annex "get" [annexedfile] "get of file"
annexed_present annexedfile
git_annex "copy" [annexedfile, "--to", "foo"] "copy --to directory remote"
annexed_present annexedfile
git_annex "drop" [annexedfile, "--numcopies=2"] "drop"
annexed_notpresent annexedfile
git_annex "move" [annexedfile, "--from", "foo"] "move --from directory remote"
annexed_present annexedfile
git_annex_shouldfail "drop" [annexedfile, "--numcopies=2"] "drop should not be allowed with numcopies=2"
annexed_present annexedfile
test_rsync_remote :: Assertion
test_rsync_remote = intmpclonerepo $ do
#ifndef mingw32_HOST_OS
createDirectory "dir"
git_annex "initremote" (words "foo type=rsync encryption=none rsyncurl=dir") "initremote"
git_annex "get" [annexedfile] "get of file"
annexed_present annexedfile
git_annex "copy" [annexedfile, "--to", "foo"] "copy --to rsync remote"
annexed_present annexedfile
git_annex "drop" [annexedfile, "--numcopies=2"] "drop"
annexed_notpresent annexedfile
git_annex "move" [annexedfile, "--from", "foo"] "move --from rsync remote"
annexed_present annexedfile
git_annex_shouldfail "drop" [annexedfile, "--numcopies=2"] "drop should not be allowed with numcopies=2"
annexed_present annexedfile
2019-08-08 17:41:56 +00:00
#else
noop
#endif
test_bup_remote :: Assertion
test_bup_remote = intmpclonerepo $ when BuildInfo.bup $ do
-- bup special remote needs an absolute path
dir <- fromRawFilePath <$> absPath (toRawFilePath "dir")
2011-12-21 17:50:33 +00:00
createDirectory dir
git_annex "initremote" (words $ "foo type=bup encryption=none buprepo="++dir) "initremote"
git_annex "get" [annexedfile] "get of file"
2011-12-21 17:50:33 +00:00
annexed_present annexedfile
git_annex "copy" [annexedfile, "--to", "foo"] "copy --to bup remote"
2011-12-21 17:50:33 +00:00
annexed_present annexedfile
git_annex "drop" [annexedfile, "--numcopies=2"] "drop"
2011-12-21 17:50:33 +00:00
annexed_notpresent annexedfile
git_annex "copy" [annexedfile, "--from", "foo"] "copy --from bup remote"
2011-12-21 17:50:33 +00:00
annexed_present annexedfile
git_annex "move" [annexedfile, "--from", "foo"] "move --from bup remote"
2011-12-21 17:50:33 +00:00
annexed_present annexedfile
2011-12-21 18:10:36 +00:00
-- gpg is not a build dependency, so only test when it's available
test_crypto :: Assertion
2013-08-04 17:07:55 +00:00
#ifndef mingw32_HOST_OS
test_crypto = do
testscheme "shared"
testscheme "hybrid"
testscheme "pubkey"
where
gpgcmd = Utility.Gpg.mkGpgCmd Nothing
testscheme scheme = do
abstmp <- fromRawFilePath <$> absPath (toRawFilePath tmpdir)
testscheme' scheme abstmp
testscheme' scheme abstmp = intmpclonerepo $ do
gpgtmp <- (</> "gpgtmp") . fromRawFilePath
<$> relPathCwdToFile (toRawFilePath abstmp)
createDirectoryIfMissing False gpgtmp
Utility.Gpg.testTestHarness gpgtmp gpgcmd
@? "test harness self-test failed"
void $ Utility.Gpg.testHarness gpgtmp gpgcmd $ do
createDirectory "dir"
let initps =
[ "foo"
, "type=directory"
, "encryption=" ++ scheme
, "directory=dir"
, "highRandomQuality=false"
] ++ if scheme `elem` ["hybrid","pubkey"]
then ["keyid=" ++ Utility.Gpg.testKeyId]
else []
git_annex "initremote" initps "initremote"
git_annex_shouldfail "initremote" initps "initremote should not work when run twice in a row"
git_annex "enableremote" initps "enableremote"
git_annex "enableremote" initps "enableremote when run twice in a row"
git_annex "get" [annexedfile] "get of file"
annexed_present annexedfile
git_annex "copy" [annexedfile, "--to", "foo"] "copy --to encrypted remote"
(c,k) <- annexeval $ do
uuid <- Remote.nameToUUID "foo"
rs <- Logs.Remote.readRemoteLog
2020-07-10 18:17:35 +00:00
Just k <- Annex.WorkTree.lookupKey (toRawFilePath annexedfile)
return (fromJust $ M.lookup uuid rs, k)
let key = if scheme `elem` ["hybrid","pubkey"]
then Just $ Utility.Gpg.KeyIds [Utility.Gpg.testKeyId]
else Nothing
testEncryptedRemote scheme key c [k] @? "invalid crypto setup"
annexed_present annexedfile
git_annex "drop" [annexedfile, "--numcopies=2"] "drop"
annexed_notpresent annexedfile
git_annex "move" [annexedfile, "--from", "foo"] "move --from encrypted remote"
annexed_present annexedfile
git_annex_shouldfail "drop" [annexedfile, "--numcopies=2"] "drop should not be allowed with numcopies=2"
annexed_present annexedfile
{- Ensure the configuration complies with the encryption scheme, and
- that all keys are encrypted properly for the given directory remote. -}
testEncryptedRemote scheme ks c keys = case Remote.Helper.Encryptable.extractCipher pc of
Just cip@Crypto.SharedCipher{} | scheme == "shared" && isNothing ks ->
checkKeys cip Nothing
Just cip@(Crypto.EncryptedCipher encipher v ks')
| checkScheme v && keysMatch ks' ->
checkKeys cip (Just v) <&&> checkCipher encipher ks'
_ -> return False
where
pc = either (const (Types.Remote.ParsedRemoteConfig mempty mempty)) id $
Remote.Helper.Encryptable.parseEncryptionConfig c
keysMatch (Utility.Gpg.KeyIds ks') =
maybe False (\(Utility.Gpg.KeyIds ks2) ->
sort (nub ks2) == sort (nub ks')) ks
checkCipher encipher = Utility.Gpg.checkEncryptionStream gpgcmd encipher . Just
checkScheme Types.Crypto.Hybrid = scheme == "hybrid"
checkScheme Types.Crypto.PubKey = scheme == "pubkey"
checkKeys cip mvariant = do
dummycfg <- Types.GitConfig.dummyRemoteGitConfig
let encparams = (Types.Remote.ParsedRemoteConfig mempty mempty, dummycfg)
cipher <- Crypto.decryptCipher gpgcmd encparams cip
files <- filterM doesFileExist $
map ("dir" </>) $ concatMap (serializeKeys cipher) keys
return (not $ null files) <&&> allM (checkFile mvariant) files
checkFile mvariant filename =
Utility.Gpg.checkEncryptionFile gpgcmd filename $
if mvariant == Just Types.Crypto.PubKey then ks else Nothing
serializeKeys cipher = map fromRawFilePath .
Annex.Locations.keyPaths .
Crypto.encryptKey Types.Crypto.HmacSha1 cipher
2013-05-17 20:49:34 +00:00
#else
2014-12-30 21:02:51 +00:00
test_crypto = putStrLn "gpg testing not implemented on Windows"
2013-05-17 20:49:34 +00:00
#endif
test_add_subdirs :: Assertion
test_add_subdirs = intmpclonerepo $ do
createDirectory "dir"
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent ("dir" </> "foo") $ "dir/" ++ content annexedfile
git_annex "add" ["dir"] "add of subdir"
{- Regression test for Windows bug where symlinks were not
- calculated correctly for files in subdirs. -}
unlessM (hasUnlockedFiles <$> getTestMode) $ do
git_annex "sync" [] "sync"
l <- annexeval $ Utility.FileSystemEncoding.decodeBL
<$> Annex.CatFile.catObject (Git.Types.Ref (encodeBS "HEAD:dir/foo"))
"../.git/annex/" `isPrefixOf` l @? ("symlink from subdir to .git/annex is wrong: " ++ l)
createDirectory "dir2"
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent ("dir2" </> "foo") $ content annexedfile
setCurrentDirectory "dir"
git_annex "add" [".." </> "dir2"] "add of ../subdir"
2015-02-10 19:20:07 +00:00
test_addurl :: Assertion
test_addurl = intmpclonerepo $ do
-- file:// only; this test suite should not hit the network
limit url downloads to whitelisted schemes Security fix! Allowing any schemes, particularly file: and possibly others like scp: allowed file exfiltration by anyone who had write access to the git repository, since they could add an annexed file using such an url, or using an url that redirected to such an url, and wait for the victim to get it into their repository and send them a copy. * Added annex.security.allowed-url-schemes setting, which defaults to only allowing http and https URLs. Note especially that file:/ is no longer enabled by default. * Removed annex.web-download-command, since its interface does not allow supporting annex.security.allowed-url-schemes across redirects. If you used this setting, you may want to instead use annex.web-options to pass options to curl. With annex.web-download-command removed, nearly all url accesses in git-annex are made via Utility.Url via http-client or curl. http-client only supports http and https, so no problem there. (Disabling one and not the other is not implemented.) Used curl --proto to limit the allowed url schemes. Note that this will cause git annex fsck --from web to mark files using a disallowed url scheme as not being present in the web. That seems acceptable; fsck --from web also does that when a web server is not available. youtube-dl already disabled file: itself (probably for similar reasons). The scheme check was also added to youtube-dl urls for completeness, although that check won't catch any redirects it might follow. But youtube-dl goes off and does its own thing with other protocols anyway, so that's fine. Special remotes that support other domain-specific url schemes are not affected by this change. In the bittorrent remote, aria2c can still download magnet: links. The download of the .torrent file is otherwise now limited by annex.security.allowed-url-schemes. This does not address any external special remotes that might download an url themselves. Current thinking is all external special remotes will need to be audited for this problem, although many of them will use http libraries that only support http and not curl's menagarie. The related problem of accessing private localhost and LAN urls is not addressed by this commit. This commit was sponsored by Brett Eisenberg on Patreon.
2018-06-15 20:52:24 +00:00
let filecmd c ps = git_annex c ("-cannex.security.allowed-url-schemes=file" : ps)
f <- fromRawFilePath <$> absPath (toRawFilePath "myurl")
let url = replace "\\" "/" ("file:///" ++ dropDrive f)
add small delay to avoid problems on systems with low-resolution mtime I've seen intermittent failures of the test suite with v6 for a long time, it seems to have possibly gotten worse with the changes around v7. Or just being unlucky; all tests failed today. Seen on amd64 and i386 builders, repeatedly but intermittently: unused: FAIL (4.86s) Test.hs:928: git diff did not show changes to unlocked file And I think other such failures, all involving v7/v6 mode tests. I managed to reproduce the unused failure with --keep-failures, and inside the repo, git diff was indeed not showing any changes for the modified unlocked file. The two stats will be the same other than mtime; the old and new files have the same size and inode, since the test case writes to the file and then overwrites it. Indeed, notice the identical timestamps: builder@orca:~/gitbuilder/build/.t/tmprepo335$ echo 1 > foo; stat foo; echo 2 > foo; stat foo File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.894942036 +0000 Change: 2018-10-29 22:14:10.894942036 +0000 Birth: - File: foo Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 3546179 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ builder) Gid: ( 1000/ builder) Access: 2018-10-29 22:14:10.894942036 +0000 Modify: 2018-10-29 22:14:10.898942036 +0000 Change: 2018-10-29 22:14:10.898942036 +0000 Birth: - I'm seeing this in Linux VMs; it doesn't happen on my laptop. I've also not experienced the intermittent test suite failures on my laptop. So, I hope that this small delay will avoid the problem. Update: I didn't, indeed I then reproduced the same failure on my laptop, so it must be due to something else. But keeping this change anyway since not needing to worry about lowish-resolution mtime in the test suite seems worthwhile.
2018-10-29 22:42:20 +00:00
writecontent f "foo"
git_annex_shouldfail "addurl" [url] "addurl should not work on file url"
filecmd "addurl" [url] ("addurl on " ++ url)
2015-02-10 19:20:07 +00:00
let dest = "addurlurldest"
filecmd "addurl" ["--file", dest, url] ("addurl on " ++ url ++ " with --file")
2015-02-10 19:20:07 +00:00
doesFileExist dest @? (dest ++ " missing after addurl --file")
2019-03-06 20:49:33 +00:00
test_export_import :: Assertion
test_export_import = intmpclonerepo $ do
2019-03-06 20:49:33 +00:00
createDirectory "dir"
git_annex "initremote" (words "foo type=directory encryption=none directory=dir exporttree=yes importtree=yes") "initremote"
git_annex "get" [] "get of files"
2019-03-06 20:49:33 +00:00
annexed_present annexedfile
-- Nothing to commit, but this makes sure the master branch
-- is in sync with the adjusted branch, which it may not be
-- depending on how the repository was set up.
commitchanges
origbranch <- annexeval origBranch
git_annex "export" [origbranch, "--to", "foo"] "export to dir"
2019-03-06 20:49:33 +00:00
dircontains annexedfile (content annexedfile)
writedir "import" (content "import")
git_annex "import" [origbranch, "--from", "foo"] "import from dir"
git_annex "merge" ["foo/" ++ origbranch] "git annex merge"
annexed_present_imported "import"
2019-03-06 20:49:33 +00:00
removeWhenExistsWith R.removeLink (toRawFilePath "import")
2019-03-06 20:49:33 +00:00
writecontent "import" (content "newimport1")
git_annex "add" ["import"] "add of import"
commitchanges
git_annex "export" [origbranch, "--to", "foo"] "export modified file to dir"
2019-03-06 20:49:33 +00:00
dircontains "import" (content "newimport1")
-- verify that export refuses to overwrite modified file
writedir "import" (content "newimport2")
removeWhenExistsWith R.removeLink (toRawFilePath "import")
2019-03-06 20:49:33 +00:00
writecontent "import" (content "newimport3")
git_annex "add" ["import"] "add of import"
commitchanges
git_annex_shouldfail "export" [origbranch, "--to", "foo"] "export should not work in conflict"
2019-03-06 20:49:33 +00:00
dircontains "import" (content "newimport2")
-- resolving import conflict
git_annex "import" [origbranch, "--from", "foo"] "import from dir"
git_shouldfail "merge" ["foo/master", "-mmerge"] "git merge of conflict should exit nonzero"
removeWhenExistsWith R.removeLink (toRawFilePath "import")
2019-03-06 20:49:33 +00:00
writecontent "import" (content "newimport3")
git_annex "add" ["import"] "add of import"
commitchanges
git_annex "export" [origbranch, "--to", "foo"] "export after import conflict"
2019-03-06 20:49:33 +00:00
dircontains "import" (content "newimport3")
where
dircontains f v =
((v==) <$> readFile ("dir" </> f))
@? ("did not find expected content of " ++ "dir" </> f)
writedir f = writecontent ("dir" </> f)
-- When on an adjusted branch, this updates the master branch
-- to match it, which is necessary since the master branch is going
-- to be exported.
commitchanges = git_annex "sync" ["--no-pull", "--no-push"] "sync"
test_export_import_subdir :: Assertion
test_export_import_subdir = intmpclonerepo $ do
createDirectory "dir"
git_annex "initremote" (words "foo type=directory encryption=none directory=dir exporttree=yes importtree=yes") "initremote"
git_annex "get" [] "get of files"
annexed_present annexedfile
createDirectory subdir
git "mv" [annexedfile, subannexedfile] "git mv"
git "commit" ["-m", "moved"] "git commit"
-- When on an adjusted branch, this updates the master branch
-- to match it, which is necessary since the master branch is going
-- to be exported.
git_annex "sync" ["--no-pull", "--no-push"] "sync"
-- Run three times because there was a bug that took a couple
-- of runs to lead to the wrong tree being written to the remote
-- tracking branch.
testimport
testexport
testimport
testexport
testimport
testexport
where
dircontains f v =
((v==) <$> readFile ("dir" </> f))
@? ("did not find expected content of " ++ "dir" </> f)
subdir = "subdir"
subannexedfile = "subdir" </> annexedfile
testexport = do
origbranch <- annexeval origBranch
git_annex "export" [origbranch++":"++subdir, "--to", "foo"] "export of subdir"
dircontains annexedfile (content annexedfile)
testimport = do
origbranch <- annexeval origBranch
git_annex "import" [origbranch++":"++subdir, "--from", "foo"] "import of subdir"
git_annex "merge" ["foo/master"] "git annex merge foo/master"
-- Make sure that import did not import the file to the top
-- of the repo.
checkdoesnotexist annexedfile