Bug 3123 - largefiles: push fails with no details if the server-side cache is corrupted
Summary: largefiles: push fails with no details if the server-side cache is corrupted
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-22 12:13 UTC by Martin Geisler
Modified: 2012-05-13 04:53 UTC (History)
9 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Geisler 2011-11-22 12:13 UTC
While pushing a large repository to a server, we somehow ended up with
corrupt files in the ~/.cache/largefiles folder on the server.

We're unsure how that happened, but it might have been triggered by a full
disk. We'll try to reproduce it later.

This bug report is about the message given to a client that pushes to such a
repository. It would be nice if we could tell a client that the server is in
trouble, or if there would be something about it in the server log file:

  $ echo "[extensions]" >> $HGRCPATH
  $ echo "largefiles =" >> $HGRCPATH

Create repositories:

  $ hg init test
  $ cd test
  $ echo foo > foo
  $ hg add --large foo
  $ hg commit -m foo

Corrupt the largefile in ~/.cache/largefiles:

  $ echo foobar > ~/.cache/largefiles/f1d2d2f924e986ac86fdf7b36c94bcdf32beec15

Serve an empty repository and try pushing into it:

  $ hg init ../empty
  $ hg serve -R ../empty -p $HGPORT -d --pid-file=hg.pid -E errors.log \
  >   --config 'web.allow_push=*' --config web.push_ssl=False
  $ cat hg.pid >> $DAEMON_PIDS

Try pushing:

  $ hg push http://localhost:$HGPORT/
  pushing to http://localhost:$HGPORT/
  searching for changes
  abort: remotestore: could not put
$TESTTMP/test/.hg/largefiles/f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 to
remote store http://localhost:$HGPORT/
  [255]

Error log:

  $ cat errors.log
Comment 1 kiilerix 2011-11-22 13:09 UTC
Is this the issue that was reported by Eli in
http://markmail.org/message/3swydmh5jojon6tm ?
Comment 2 Eli Carter 2011-11-22 13:16 UTC
In the case I described, the error was due to not having the largefiles
extension enabled on the server.  But I'm sure it's related in terms of not
providing a useful error message back to the client.
Comment 3 Martin Geisler 2011-11-29 01:56 UTC
The server-side corruption issue should be fixed by 809788118aa2 and 926bc23d0b6a which will be in Mercurial 2.1.
Comment 4 Matt Mackall 2011-11-29 11:51 UTC
They're on the stable branch, so they'll be in 2.0.1 on Thursday.
Comment 5 Martin Geisler 2011-11-30 02:40 UTC
Ah, right, I don't know how I got the version numbers mixed up like that.
Comment 6 Na'Tosha Bard 2011-12-28 08:44 UTC
Marking as resolved; fix is already released.
Comment 7 Matt Mackall 2011-12-28 11:37 UTC
I'm not aware of a fix that addresses the actual issue raised in $TITLE.
I suspect it's closely related to issue3149, which is a debugging nightmare.
Reopening.
Comment 8 HG Bot 2012-01-06 01:00 UTC
Fixed by http://selenic.com/repo/hg/rev/f15c646bffc7
Kevin Gessner <kevin@fogcreek.com>
largefiles: display remote errors from putlfile (issue3123) (issue3149)

(please test the fix)
Comment 9 Bugzilla 2012-05-12 09:25 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:25 EDT  ---

This bug was previously known as _bug_ 3123 at http://mercurial.selenic.com/bts/issue3123