mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

work around box.com webdav rename bug

Browse source 
Apparently box.com renaming is just buggy. I tried a couple of fixes:

* In case the http Manager was opening multiple connections and reaching
  different backend servers, I tried limiting the number of connections
  to 1. Didn't help.
* To make sure it was not a http connection reuse problem, I tried
  rewriting how exportAction works, so that the same http connection
  is clearly open. Didn't help.

So, disable renaming of exports for box.com. It would be good to test it
with some other webdav server.

This commit was sponsored by John Peloquin on Patreon.
This commit is contained in:
Joey Hess 2017-09-13 15:09:52 -04:00
parent 955c616956
commit bf48ba4ef7
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 16 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
Remote/WebDAV.hs
View file

@ -201,9 +201,15 @@ checkPresentExportDav r mh _k loc = case mh of
either giveup return v either giveup return v
renameExportDav :: Maybe DavHandle -> Key -> ExportLocation -> ExportLocation -> Annex Bool renameExportDav :: Maybe DavHandle -> Key -> ExportLocation -> ExportLocation -> Annex Bool
renameExportDav mh _k src dest = runExport mh $ \dav -> do renameExportDav Nothing _ _ _ = return False
moveDAV (baseURL dav) (exportLocation src) (exportLocation dest) renameExportDav (Just h) _k src dest
return True -- box.com's DAV endpoint has buggy handling of renames,
-- so avoid renaming when using it.
| boxComUrl `isPrefixOf` baseURL h = return False
| otherwise = runExport (Just h) $ \dav -> do
maybe noop (void . mkColRecursive) (locationParent (exportLocation dest))
moveDAV (baseURL dav) (exportLocation src) (exportLocation dest)
return True
runExport :: Maybe DavHandle -> (DavHandle -> DAVT IO Bool) -> Annex Bool runExport :: Maybe DavHandle -> (DavHandle -> DAVT IO Bool) -> Annex Bool
runExport Nothing _ = return False runExport Nothing _ = return False
@ -213,7 +219,10 @@ configUrl :: Remote -> Maybe URLString
configUrl r = fixup <$> M.lookup "url" (config r) configUrl r = fixup <$> M.lookup "url" (config r)
where where
-- box.com DAV url changed -- box.com DAV url changed
fixup = replace "https://www.box.com/dav/" "https://dav.box.com/dav/" fixup = replace "https://www.box.com/dav/" boxComUrl
boxComUrl :: URLString
boxComUrl = "https://dav.box.com/dav/"
type DavUser = B8.ByteString type DavUser = B8.ByteString
type DavPass = B8.ByteString type DavPass = B8.ByteString

12
doc/todo/export.mdwn
View file

@ -40,12 +40,6 @@ Low priority:
Run each pair in turn. Then run the current rename code. Although this Run each pair in turn. Then run the current rename code. Although this
still probably misses cases, where eg, content cycles amoung 3 files, and still probably misses cases, where eg, content cycles amoung 3 files, and
the same content amoung 3 other files. Is there a general algorythm? the same content amoung 3 other files. Is there a general algorythm?
* Exporting to box.com via webdav, a rename of a file behaves * webdav: When a file in a subdirectory gets deleted,
oddly. The rename to the temp file succeeds, but the rename of the temp the webdav collection is remains, empty. Need to check if collection is
file to the final name fails. empty, and delete otherwise.
Also, sometimes the delete of the temp file that's done as a fallback
fails to actually delete it.
Hypothesis: Those are done in separate http connections and it might be
talking to two different backend servers that are out of sync.
So, making export cache connections might help. Update: No, caching
connections did not solve it.