diff --git a/Annex/Content.hs b/Annex/Content.hs --- a/Annex/Content.hs +++ b/Annex/Content.hs @@ -379,7 +379,7 @@ - when doing concurrent downloads. -} checkDiskSpace :: Maybe FilePath -> Key -> Integer -> Bool -> Annex Bool -checkDiskSpace destination key alreadythere samefilesystem = ifM (Annex.getState Annex.force) +checkDiskSpace destdir key alreadythere samefilesystem = ifM (Annex.getState Annex.force) ( return True , do -- We can't get inprogress and free at the same @@ -403,7 +403,7 @@ _ -> return True ) where - dir = maybe (fromRepo gitAnnexDir) return destination + dir = maybe (fromRepo gitAnnexDir) return destdir needmorespace n = warning $ "not enough free space, need " ++ roughSize storageUnits True n ++ diff --git a/BuildFlags.hs b/BuildFlags.hs --- a/BuildFlags.hs +++ b/BuildFlags.hs @@ -37,6 +37,12 @@ #endif #ifdef WITH_S3 , "S3" +#if MIN_VERSION_aws(0,10,6) + ++ "(multipartupload)" +#endif +#if MIN_VERSION_aws(0,13,0) + ++ "(storageclasses)" +#endif #else #warning Building without S3. #endif diff --git a/CHANGELOG b/CHANGELOG --- a/CHANGELOG +++ b/CHANGELOG @@ -1,3 +1,16 @@ +git-annex (5.20151218) unstable; urgency=medium + + * Add S3 features to git-annex version output. + * webdav: When testing the WebDAV server, send a file with content. + The empty file it was sending tickled bugs in some php WebDAV server. + * fsck: Failed to honor annex.diskreserve when checking a remote. + * Debian: Build depend on concurrent-output. + * Fix insecure temporary permissions when git-annex repair is used in + in a corrupted git repository. + * Fix potential denial of service attack when creating temp dirs. + + -- Joey Hess Fri, 18 Dec 2015 12:09:33 -0400 + git-annex (5.20151208) unstable; urgency=medium * Build with -j1 again to get reproducible build. diff --git a/Command/Fsck.hs b/Command/Fsck.hs --- a/Command/Fsck.hs +++ b/Command/Fsck.hs @@ -162,7 +162,7 @@ let cleanup = liftIO $ catchIO (removeFile tmp) (const noop) cleanup cleanup `after` a tmp - getfile tmp = ifM (checkDiskSpace (Just tmp) key 0 True) + getfile tmp = ifM (checkDiskSpace (Just (takeDirectory tmp)) key 0 True) ( ifM (Remote.retrieveKeyFileCheap remote key (Just file) tmp) ( return (Just True) , ifM (Annex.getState Annex.fast) diff --git a/Remote/WebDAV.hs b/Remote/WebDAV.hs --- a/Remote/WebDAV.hs +++ b/Remote/WebDAV.hs @@ -191,7 +191,7 @@ makeParentDirs void $ mkColRecursive tmpDir inLocation (tmpLocation "git-annex-test") $ do - putContentM (Nothing, L.empty) + putContentM (Nothing, L8.fromString "test") delContentM where test a = liftIO $ diff --git a/Utility/FileMode.hs b/Utility/FileMode.hs --- a/Utility/FileMode.hs +++ b/Utility/FileMode.hs @@ -27,12 +27,24 @@ {- Applies a conversion function to a file's mode. -} modifyFileMode :: FilePath -> (FileMode -> FileMode) -> IO () -modifyFileMode f convert = do +modifyFileMode f convert = void $ modifyFileMode' f convert + +modifyFileMode' :: FilePath -> (FileMode -> FileMode) -> IO FileMode +modifyFileMode' f convert = do s <- getFileStatus f let old = fileMode s let new = convert old when (new /= old) $ setFileMode f new + return old + +{- Runs an action after changing a file's mode, then restores the old mode. -} +withModifiedFileMode :: FilePath -> (FileMode -> FileMode) -> IO a -> IO a +withModifiedFileMode file convert a = bracket setup cleanup go + where + setup = modifyFileMode' file convert + cleanup oldmode = modifyFileMode file (const oldmode) + go _ = a {- Adds the specified FileModes to the input mode, leaving the rest - unchanged. -} diff --git a/Utility/Tmp.hs b/Utility/Tmp.hs --- a/Utility/Tmp.hs +++ b/Utility/Tmp.hs @@ -15,6 +15,9 @@ import Control.Monad.IfElse import System.FilePath import Control.Monad.IO.Class +#ifndef mingw32_HOST_OS +import System.Posix.Temp (mkdtemp) +#endif import Utility.Exception import Utility.FileSystemEncoding @@ -64,25 +67,22 @@ - directory and all its contents. -} withTmpDir :: (MonadMask m, MonadIO m) => Template -> (FilePath -> m a) -> m a withTmpDir template a = do - tmpdir <- liftIO $ catchDefaultIO "." getTemporaryDirectory - withTmpDirIn tmpdir template a + topleveltmpdir <- liftIO $ catchDefaultIO "." getTemporaryDirectory +#ifndef mingw32_HOST_OS + -- Use mkdtemp to create a temp directory securely in /tmp. + bracket + (liftIO $ mkdtemp $ topleveltmpdir template) + removeTmpDir + a +#else + withTmpDirIn topleveltmpdir template a +#endif {- Runs an action with a tmp directory located within a specified directory, - then removes the tmp directory and all its contents. -} withTmpDirIn :: (MonadMask m, MonadIO m) => FilePath -> Template -> (FilePath -> m a) -> m a -withTmpDirIn tmpdir template = bracketIO create remove +withTmpDirIn tmpdir template = bracketIO create removeTmpDir where - remove d = whenM (doesDirectoryExist d) $ do -#if mingw32_HOST_OS - -- Windows will often refuse to delete a file - -- after a process has just written to it and exited. - -- Because it's crap, presumably. So, ignore failure - -- to delete the temp directory. - _ <- tryIO $ removeDirectoryRecursive d - return () -#else - removeDirectoryRecursive d -#endif create = do createDirectoryIfMissing True tmpdir makenewdir (tmpdir template) (0 :: Int) @@ -91,6 +91,21 @@ catchIOErrorType AlreadyExists (const $ makenewdir t $ n + 1) $ do createDirectory dir return dir + +{- Deletes the entire contents of the the temporary directory, if it + - exists. -} +removeTmpDir :: MonadIO m => FilePath -> m () +removeTmpDir tmpdir = liftIO $ whenM (doesDirectoryExist tmpdir) $ do +#if mingw32_HOST_OS + -- Windows will often refuse to delete a file + -- after a process has just written to it and exited. + -- Because it's crap, presumably. So, ignore failure + -- to delete the temp directory. + _ <- tryIO $ removeDirectoryRecursive tmpdir + return () +#else + removeDirectoryRecursive tmpdir +#endif {- It's not safe to use a FilePath of an existing file as the template - for openTempFile, because if the FilePath is really long, the tmpfile diff --git a/debian/changelog b/debian/changelog --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,16 @@ +git-annex (5.20151218) unstable; urgency=medium + + * Add S3 features to git-annex version output. + * webdav: When testing the WebDAV server, send a file with content. + The empty file it was sending tickled bugs in some php WebDAV server. + * fsck: Failed to honor annex.diskreserve when checking a remote. + * Debian: Build depend on concurrent-output. + * Fix insecure temporary permissions when git-annex repair is used in + in a corrupted git repository. + * Fix potential denial of service attack when creating temp dirs. + + -- Joey Hess Fri, 18 Dec 2015 12:09:33 -0400 + git-annex (5.20151208) unstable; urgency=medium * Build with -j1 again to get reproducible build. diff --git a/debian/control b/debian/control --- a/debian/control +++ b/debian/control @@ -71,6 +71,7 @@ libghc-tasty-rerun-dev, libghc-optparse-applicative-dev (>= 0.11.0), libghc-torrent-dev, + libghc-concurrent-output-dev, lsof [linux-any], ikiwiki, perlmagick, diff --git a/doc/bugs/Low_disk_space_corrupts_state.mdwn b/doc/bugs/Low_disk_space_corrupts_state.mdwn new file mode 100644 --- /dev/null +++ b/doc/bugs/Low_disk_space_corrupts_state.mdwn @@ -0,0 +1,61 @@ +### Please describe the problem. + +When there are low disk space left, changes in the annex repo are only semi updated, leaving the dir and git annex state out of sync, leaving error messages with "invalid objects" and "fatal: git-write-tree: error building trees". + +I ignored these errors, and kept on trying to copy over all the files to a remote disk, since I wanted a backup, which resultet in symlinks pointing to files which aren't there. + +Maybe git-annex should stop if it sees that it's not enough disk space to perform a certain operation? E.g. cache space needed for syncing. + +### What steps will reproduce the problem? + +I'm not certain about what command that created the issue, but i ran various commands: + +- `git annex sync EXTERNALREPO` +- `git annex copy --to EXTERNALREPO` +- `git annex unlock Videos/` +- `git annex lock Videos/` + +My disk had 280MB left, and the repo were at a few GBs. Somewhere in between these commands, git-annex started producing a lot of error messages for various files. + +### What version of git-annex are you using? On what operating system? + +git-annex version: 5.20140717 (Fedora 23) + +### Please provide any additional information below. + +Unfortunately, I don't have the full transcript of my badly behaved commands. Instead I add some of the error messages: + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + + $ git annex lock Videos/ + error: invalid object 100644 56715f46d9256bdcef0cd387364818e597dc9f41 for '003/a56/SHA256-s23430--26dc3b33a5101e4ead217241a371b17f15e7a2f37bbcaedd0d35a0a1aa4eb9b0.log.cnk' + fatal: git-write-tree: error building trees + git-annex: failed to read sha from git write-tree + + $ git annex sync + error: refs/remotes/remote_annex/synced/master does not point to a valid object! + error: refs/remotes/home/synced/master does not point to a valid object! + error: refs/remotes/work_annex/synced/master does not point to a valid object! + error: refs/remotes/home_annex/synced/master does not point to a valid object! + error: refs/remotes/home/synced/master does not point to a valid object! + error: refs/remotes/work_annex/synced/master does not point to a valid object! + error: Could not read bf3d6640fa32460032926ae6... + fatal: revision walk setup failed + error: Could not read 8cdec1808723971eaf30e32... + fatal: revision walk setup failed + (merging work/git-annex into git-annex...) + fatal: unable to read tree 21e0681190de239f41d... + (Recording state in git...) + error: invalid object 100644 56715f36d9256bdeff... for '003/a56/SHA256-s23430--2dc3b411e5ead...log.cnk' + fatal: git-write-tree: error building trees + git-annex: failed to read sha from git write-tree + +# End of transcript or log. +"""]] + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) + +It worked as a charm until my disk got full! (Maybe it is better to split it up in various, smaller repos, and sync them individually?) diff --git a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn --- a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn +++ b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn @@ -6,7 +6,7 @@ Help me prioritize my work: What special remote would you most like to use with the git-annex assistant? -[[!poll open=yes 18 "Amazon S3 (done)" 13 "Amazon Glacier (done)" 10 "Box.com (done)" 74 "My phone (or MP3 player)" 27 "Tahoe-LAFS" 16 "OpenStack SWIFT" 37 "Google Drive"]] +[[!poll open=yes 18 "Amazon S3 (done)" 13 "Amazon Glacier (done)" 10 "Box.com (done)" 75 "My phone (or MP3 player)" 27 "Tahoe-LAFS" 16 "OpenStack SWIFT" 37 "Google Drive"]] This poll is ordered with the options I consider easiest to build listed first. Mostly because git-annex already supports them and they diff --git a/doc/design/encryption.mdwn b/doc/design/encryption.mdwn --- a/doc/design/encryption.mdwn +++ b/doc/design/encryption.mdwn @@ -4,18 +4,6 @@ [[!toc]] -## encryption backends - -It makes sense to support multiple encryption backends. So, there -should be a way to tell what backend is responsible for a given filename -in an encrypted remote. (And since special remotes can also store files -unencrypted, differentiate from those as well.) - -The rest of this page will describe a single encryption backend using GPG. -Probably only one will be needed, but who knows? Maybe that backend will -turn out badly designed, or some other encryptor needed. Designing -with more than one encryption backend in mind helps future-proofing. - ## encryption key management [[!template id=note text=""" @@ -35,18 +23,22 @@ Different encrypted remotes need to be able to each use different ciphers. Allowing multiple ciphers to be used within a single remote would add a lot -of complexity, so is not planned to be supported. +of complexity, so is not supported. Instead, if you want a new cipher, create a new S3 bucket, or whatever. There does not seem to be much benefit to using the same cipher for two different encrypted remotes. -So, the encrypted cipher could just be stored with the rest of a remote's +So, the encrypted cipher is just stored with the rest of a remote's configuration in `remotes.log` (see [[internals]]). When `git -annex intiremote` makes a remote, it can generate a random symmetric +annex intiremote` makes a remote, it generates a random symmetric cipher, and encrypt it with the specified gpg key. To allow another gpg public key access, update the encrypted cipher to be encrypted to both gpg keys. +Note that there's a shared encryption mode where the cipher is not +encrypted. When this mode is used, any clone of the git repository +can decrypt files stored in its special remote. + ## filename enumeration If the names of files are encrypted or securely hashed, or whatever is @@ -73,7 +65,8 @@ It was suggested that it might not be wise to use the same cipher for both gpg and HMAC. Being paranoid, it's best not to tie the security of one to the security of the other. So, the encrypted cipher described above is -actually split in two; half is used for HMAC, and half for gpg. +actually split in two; the first half is used for HMAC, and the second +half for gpg. ---- @@ -101,6 +94,9 @@ the cipher can get access to whatever other credentials are needed to use the special remote. +For example, the S3 special remote does this if configured with +embedcreds=yet. + ## risks A risk of this scheme is that, once the symmetric cipher has been @@ -118,9 +114,5 @@ filenames and metadata of files stored in the encrypted remote anyway, and can access whatever content is stored locally. -This design does not support obfuscating the size of files by chunking -them, as that would have added a lot of complexity, for dubious benefits. -If the untrusted party running the encrypted remote wants to know file sizes, -they could correlate chunks that are accessed together. Encrypting data -changes the original file size enough to avoid it being used as a direct -fingerprint at least. +This design does not address obfuscating the size of files by chunking +them. However, chunking was later added; see [[design/assistant/chunks]]. diff --git a/doc/devblog/day_343__get_and_drop_for_smudge.mdwn b/doc/devblog/day_343__get_and_drop_for_smudge.mdwn new file mode 100644 --- /dev/null +++ b/doc/devblog/day_343__get_and_drop_for_smudge.mdwn @@ -0,0 +1,26 @@ +Well, another day working on smudge filters, or unlocked files as the +feature will be known when it's ready. Got both `git annex get` and `git +annex drop` working for these files today. + +Get was the easy part; it just has to hard link or copy the object to the +work tree file(s) that point to it. + +Handling dropping was hard. If the user drops a file, but it's unlocked and +modified, it shouldn't reset it to the pointer file. For this, I reused the +InodeCache stuff that was built for direct mode. So the sqlite database +tracks the InodeCaches of unlocked files, and when a key is dropped it can +check if the file is modified. + +But that's not a complete solution, because when git uses a clean filter, +it will write the file itself, and git-annex won't have an InodeCache for +it. To handle this case, git-annex will fall back to verifying the content +of the file when dropping it if its InodeCache isn't known. +Bit of a shame to need an expensive checksum to drop an unlocked file; +maybe the git clean filter interface will eventually be improved to let +git-annex use it more efficiently. + +Anyway, smudged aka unlocked files are working now well enough to be a +proof of concept. I have several missing safety checks that need to be +added to get the implementation to be really correct, and quite a lot +of polishing still to do, including making `unlock`, `lock`, `fsck`, +and `merge` handle them, and finishing repository upgrade code. diff --git a/doc/devblog/day_344-345__smudging_along.mdwn b/doc/devblog/day_344-345__smudging_along.mdwn new file mode 100644 --- /dev/null +++ b/doc/devblog/day_344-345__smudging_along.mdwn @@ -0,0 +1,7 @@ +New special remote alert! Chris Kastorff has made +[a special remote supporting Backblaze's B2 storage servie](https://github.com/encryptio/git-annex-remote-b2). + +And I'm still working on v6 unlocked files. After beating on it for 2 more +days, all git-annex commands should support them. There is still plenty +of work to do on testing, upgrading, optimisation, merge conflict resolution, +and reconciling staged changes. diff --git a/doc/devblog/day_346-347__nearly_ready_to_merge.mdwn b/doc/devblog/day_346-347__nearly_ready_to_merge.mdwn new file mode 100644 --- /dev/null +++ b/doc/devblog/day_346-347__nearly_ready_to_merge.mdwn @@ -0,0 +1,19 @@ +Two more days working on v6 and the `smudge` branch is almost ready to be +merged. The test suite is passing again for v5 repos, and is almost +passing for v6 repos. Also I decided to make `git annex init` create v5 +repos for now, so `git annex init --version=6` or a `git annex upgrade` +is needed to get a v6 repo. So while I still have plenty of todo items for +v6 repos, they are working reasonably well and almost ready for early +adopters. + +The only real blocker to merging it is that the database stuff used by v6 +is not optimised yet and probably slow, and even in v5 repos it will query +the database. I hope to find an optimisation that avoids all database +overhead unless unlocked files are used in a v6 repo. + +I'll probably make one more release before that is merged though. Yesterday +I fixed a small security hole in `git annex repair`, which could expose the +contents of an otherwise not world-writable repository to local users. + +BTW, the [2015 git-annex user survey](http://git-annex-survey.branchable.com/polls/2015/) +closes in two weeks, please go fill it out if you haven't yet done so! diff --git a/doc/forum/All_repos_on_same_filesystem.mdwn b/doc/forum/All_repos_on_same_filesystem.mdwn new file mode 100644 --- /dev/null +++ b/doc/forum/All_repos_on_same_filesystem.mdwn @@ -0,0 +1,14 @@ +Hi, + I am looking to find out the best way to use git annex, when all repos will live on the same filesystem, using a central repo. + +What I have so far is, after creating the main repo (mainrepo). + +Create clones via: git clone -shared mainrepo clonerepo + +Then use "git annex add" and "git add". When it comes to making the data accessible to the mainrepo, it is a little unclear to me. +There is a lot of disjoint information regarding pull/pushing content and which directions use hardlinks vs copies etc. So I +was hoping that someone could fill me in on best practices. + +Thanks in advance! + +Pete diff --git a/doc/forum/Can__39__t_upload_data_to_glacier_remote.mdwn b/doc/forum/Can__39__t_upload_data_to_glacier_remote.mdwn new file mode 100644 --- /dev/null +++ b/doc/forum/Can__39__t_upload_data_to_glacier_remote.mdwn @@ -0,0 +1,55 @@ +I'm trying to follow the directions on [this tips page](https://git-annex.branchable.com/tips/using_Amazon_Glacier/) to easily back up some large home videos to Glacier. I followed the steps and everything worked fine until the `git annex copy`, at which point it claimed it was successful but had uploaded 0 bytes, as well as dumping the usage message for `glacier-cli` at the terminal (without any error): + + Emily $ git annex copy --to glacier README + copy README (gpg) (checking glacier...) (to glacier...) + 100% 0.0 B/s 0s + glacier [args] + + Commands + vaults - Operations with vaults + jobs - Operations with jobs + upload - Upload files to a vault. If the vault doesn't exits, it is + created + + Common args: + --access_key - Your AWS Access Key ID. If not supplied, boto will + use the value of the environment variable + AWS_ACCESS_KEY_ID + --secret_key - Your AWS Secret Access Key. If not supplied, boto + will use the value of the environment variable + AWS_SECRET_ACCESS_KEY + --region - AWS region to use. Possible values: us-east-1, us-west-1, + us-west-2, ap-northeast-1, eu-west-1. + Default: us-east-1 + + Vaults operations: + + List vaults: + glacier vaults + + Jobs operations: + + List jobs: + glacier jobs + + Uploading files: + + glacier upload + + Examples : + glacier upload pics *.jpg + glacier upload pics a.jpg b.jpg + + ok + (Recording state in git...) + +Doing a `glacier vaults` also does not show any new vaults, and getting the usage message is obviously not normal. + +I tried doing a manual upload to a vault I already had sitting around from some years ago called `TVault`, and that looked to work fine: + + Emily $ glacier upload TVault README + Uploading README to TVault... done. Vault returned ArchiveID [omitted] + +(The update date hasn't updated on the management console yet, but I understand that may take up to a day.) + +Does anyone know what's going on, or is there at least a way to get a useful error message to output? diff --git a/doc/news/version_5.20151019.mdwn b/doc/news/version_5.20151019.mdwn deleted file mode 100644 --- a/doc/news/version_5.20151019.mdwn +++ /dev/null @@ -1,53 +0,0 @@ -git-annex 5.20151019 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Fix a longstanding, but unlikely to occur bug, where dropping - a file from a remote could race with other drops of the same file, - and result in all copies of its content being lost. - * git-annex-shell: Added lockcontent command, to prevent dropping of - a key's content. This is necessary due to the above bugfix. - * In some cases, the above bugfix changes what git-annex allows you to - drop: - - When a file is present in several special remotes, - but not in any accessible git repositories, dropping it from one of - the special remotes will now fail. Instead, the file has to be - moved from one of the special remotes to the git repository, and can - then safely be dropped from the git repository. - - If a git remote has too old a version of git-annex-shell installed, - git-annex won't trust it to hold onto a copy of a file when dropping - that file from the local git repository. - * Changed drop ordering when using git annex sync --content or the - assistant, to drop from remotes first and from the local repo last. - This works better with the behavior changes to drop in many cases. - * Do verification of checksums of annex objects downloaded from remotes. - * When annex objects are received into git repositories from other git - repos, their checksums are verified then too. - * To get the old, faster, behavior of not verifying checksums, set - annex.verify=false, or remote.<name>.annex-verify=false. - * setkey, rekey: These commands also now verify that the provided file - matches the expected checksum of the key, unless annex.verify=false. - * reinject: Already verified content; this can now be disabled by - setting annex.verify=false. - * sync, merge, assistant: When git merge failed for a reason other - than a conflicted merge, such as a crippled filesystem not allowing - particular characters in filenames, git-annex would make a merge commit - that could omit such files or otherwise be bad. Fixed by aborting the - whole merge process when git merge fails for any reason other than a - merge conflict. - * Allow building with S3 disabled again. - * Ported disk free space checking code to work on Solaris. - * Windows webapp: Fix support for entering password when setting - up a ssh remote. - * copy --auto was checking the wrong repo's preferred content. - (--from was checking what --to should, and vice-versa.) - Fixed this bug, which was introduced in version 5.20150727. - * Avoid unncessary write to the location log when a file is unlocked - and then added back with unchanged content. - * S3: Fix support for using https. - * Avoid displaying network transport warning when a ssh remote - does not yet have an annex.uuid set. - * Debian: Add torrent library to build-depends as it's packaged now, - and stop recommending bittornado | bittorrent. - * Debian: Remove build dependency on transformers library, as it is now - included in ghc. - * Debian: Remove menu file, since a desktop file is provided and - lintian says there can be only one."""]] diff --git a/doc/news/version_5.20151218.mdwn b/doc/news/version_5.20151218.mdwn new file mode 100644 --- /dev/null +++ b/doc/news/version_5.20151218.mdwn @@ -0,0 +1,10 @@ +git-annex 5.20151218 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * Add S3 features to git-annex version output. + * webdav: When testing the WebDAV server, send a file with content. + The empty file it was sending tickled bugs in some php WebDAV server. + * fsck: Failed to honor annex.diskreserve when checking a remote. + * Debian: Build depend on concurrent-output. + * Fix insecure temporary permissions when git-annex repair is used in + in a corrupted git repository. + * Fix potential denial of service attack when creating temp dirs."""]] diff --git a/doc/special_remotes.mdwn b/doc/special_remotes.mdwn --- a/doc/special_remotes.mdwn +++ b/doc/special_remotes.mdwn @@ -44,6 +44,7 @@ * [pCloud](https://github.com/tochev/git-annex-remote-pcloud) * [[ipfs]] * [Ceph](https://github.com/mhameed/git-annex-remote-ceph) +* [Blackblaze's B2](https://github.com/encryptio/git-annex-remote-b2) Want to add support for something else? [[Write your own!|external]] diff --git a/doc/special_remotes/S3/comment_21_26cbfd805dd45a80121f5e2079afba37._comment b/doc/special_remotes/S3/comment_21_26cbfd805dd45a80121f5e2079afba37._comment new file mode 100644 --- /dev/null +++ b/doc/special_remotes/S3/comment_21_26cbfd805dd45a80121f5e2079afba37._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 21""" + date="2015-12-10T15:20:43Z" + content=""" +@cantora with a recent enough version of git-annex, `git annex info +$theremotename` will show quite a lot of information about a special +remote, including encryption details. +"""]] diff --git a/doc/special_remotes/comment_30_8e5b17431507ee2115b992e5156b749b._comment b/doc/special_remotes/comment_30_8e5b17431507ee2115b992e5156b749b._comment new file mode 100644 --- /dev/null +++ b/doc/special_remotes/comment_30_8e5b17431507ee2115b992e5156b749b._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" + subject="anyone saw/worked on backend for watchdox service? (not free one but needed :-/)" + date="2015-12-08T19:45:02Z" + content=""" +subject +"""]] diff --git a/doc/special_remotes/comment_31_20ac13d009a4f451eb895ca16446ba88._comment b/doc/special_remotes/comment_31_20ac13d009a4f451eb895ca16446ba88._comment new file mode 100644 --- /dev/null +++ b/doc/special_remotes/comment_31_20ac13d009a4f451eb895ca16446ba88._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="openmedi" + subject="comment 31" + date="2015-12-09T20:18:48Z" + content=""" +How does git-annex handle space issues with special remotes? For example my Owncloud instance has 100 GB space. What happens if I run out of space on that remote? Does git-annex handle that gracefully? Do I have to do something? Can I set a sort of \"quota\"? +"""]] diff --git a/doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment b/doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment new file mode 100644 --- /dev/null +++ b/doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 32""" + date="2015-12-10T15:15:42Z" + content=""" +@openmedi git-annex doesn't currently keep track of how much space it's +using on a special remote. It's actually quite a difficult problem to do +that in general, since multiple distributed clones of a repository can be +uploading to the same special remote at the same time. + +If it runs out of space and transfers fail, git-annex will handle the +failures semi-gracefully, which is to say nothing will stop it from trying +again or trying to send other data, but it will certianly be aware that +files are not reaching the special remote. + +If a particular storage service has a way to check free space, it would not +be hard to make git-annex's special remote implementation check it and +avoid trying transfers when it's full. +"""]] diff --git a/git-annex.cabal b/git-annex.cabal --- a/git-annex.cabal +++ b/git-annex.cabal @@ -1,5 +1,5 @@ Name: git-annex -Version: 5.20151208 +Version: 5.20151218 Cabal-Version: >= 1.8 License: GPL-3 Maintainer: Joey Hess diff --git a/man/git-annex-smudge.1 b/man/git-annex-smudge.1 --- a/man/git-annex-smudge.1 +++ b/man/git-annex-smudge.1 @@ -12,11 +12,7 @@ .PP When adding a file with \fBgit add\fP, the annex.largefiles config is consulted to decide if a given file should be added to git as\-is, -or if its content are large enough to need to use git-annex. To force a -file that would normally be added to the annex to be added to git as\-is, -this can be temporarily overridden. For example: -.PP - git \-c annex.largefiles='exclude=*' add myfile +or if its content are large enough to need to use git-annex. .PP The git configuration to use this command as a filter driver is as follows. This is normally set up for you by git-annex init, so you should