"Unrecognised container format" after push to FTP server with broken APPE
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Low
|
Unassigned | ||
Breezy |
Won't Fix
|
Low
|
Unassigned |
Bug Description
On my server, I'm running bzr 1.7. My client on my windows system is 1.7. My co-developer's client on a mac system is the latest stable as of last week (I'll find out when he logs on again).
When I push to my server, everything works fine, well and great. This has held true for many projects over the last year or so, after going through upgrades on both the server and my client.
When my co-developer pushes to the server, the repository gets corrupted. I'd seen this once before, but merely killed the repo and repushed when I couldn't find a solution in the past. This time I'd like to resolve the issue if possible.
When I try a bzr log (or update or much of anything) I get the following message:
bzr: ERROR: Unrecognised container format: 'B1109'
Per the advice of the kind folk at #bzr it tried:
for i in .bzr/repository
Which shows that 2 of the files do not have their proper header:
.bzr/repository
Bazaar pack format 1 (introduced in 0.18)
B392
.bzr/repository
B1109
.bzr/repository
Bazaar pack format 1 (introduced in 0.18)
B371
...
.bzr/repository
B363
.bzr/repository
Bazaar pack format 1 (introduced in 0.18)
B367
I've also noticed something else that's a bit odd. If I list the files in the pack directory, the 2 files without their proper header have different permissions than the others:
-rwxr-xr-x 1 enobrev.info enobrev.info 4616 Dec 3 06:59 83f4b2bef2a6c44
-rw-r--r-- 1 enobrev.info enobrev.info 15711 Nov 30 04:33 c68a2940591c95c
-rw-r--r-- 1 enobrev.info enobrev.info 2454468 Nov 30 02:46 76b68498954878e
-rwxr-xr-x 1 enobrev.info enobrev.info 259643 Dec 3 06:59 0b839c4de16a814
I tried adding the header myself via vim, but then I get:
bzr: ERROR: Unknown record type: '\xc7'
Here's the Trace Log:
2.102 Traceback (most recent call last):
File "/home/
return run_bzr(argv)
File "/home/
ret = run(*run_argv)
File "/home/
return self.run(
File "/home/
check_
File "/home/
result = repo.check()
File "/home/
result = unbound(self, *args, **kwargs)
File "/home/
return self._check(
File "/home/
result.check()
File "/home/
self.
File "/home/
bad_revisions = self.repository
File "/home/
revs = self.get_
File "/home/
result = unbound(self, *args, **kwargs)
File "/home/
return self._get_
File "/home/
result = unbound(self, *args, **kwargs)
File "/home/
for record in stream:
File "/home/
needed_
File "/home/
record_map = self._get_
File "/home/
self.
File "/home/
izip(
File "/home/
for names, read_func in reader.
File "/home/
self.
File "/home/
raise errors.
UnknownContaine
2.102 return code 3
I can't find any info about this anywhere. Please help!!
Mark
Related branches
- Vincent Ladeuil: Approve
- Martin Packman: Approve
-
Diff: 1510 lines (+17/-1308)16 files modifiedbreezy/help_topics/en/authentication.txt (+3/-3)
breezy/lockdir.py (+0/-3)
breezy/plugins/git/tests/test_dir.py (+1/-1)
breezy/plugins/upload/__init__.py (+1/-1)
breezy/plugins/upload/tests/test_upload.py (+1/-25)
breezy/tests/__init__.py (+0/-6)
breezy/tests/blackbox/test_help.py (+0/-2)
breezy/tests/ftp_server/__init__.py (+0/-82)
breezy/tests/ftp_server/pyftpdlib_based.py (+0/-223)
breezy/tests/test_ftp_transport.py (+0/-151)
breezy/tests/test_http.py (+2/-2)
breezy/tests/test_smart_transport.py (+1/-1)
breezy/tests/transport_util.py (+8/-19)
breezy/transport/__init__.py (+0/-23)
breezy/transport/ftp/__init__.py (+0/-638)
breezy/transport/ftp/_gssapi.py (+0/-128)
tags: | added: check-for-breezy |
Changed in brz: | |
status: | New → Triaged |
importance: | Undecided → Low |
tags: | removed: check-for-breezy |
Changed in brz: | |
status: | Triaged → Won't Fix |
There was a bug in an old version of paramiko such that doing an "append" actually caused a write to occur at the beginning of the file.
the "B1109" is saying that what follows is a byte-stream of length 1109. And it sounds like whatever he is doing is causing the pack header to either
a) Not be written, or
b) Get overwritten
What does he use to do the his push? (bzr+ssh, network mount, sftp, etc?)
I would guess he hasn't corrupted any existing packs, because we don't write into them. Though it is possible his client wanted to do an autopack and would copy data across, etc.
Certainly something serious seems to be happening if we are saying "Append these 50 bytes" and it is being turned into "write these 50 bytes at the beginning of the file".