add workaround for Windows/IIS6 FTP server strangeness causing unlock failures.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Wishlist
|
Unassigned | ||
Breezy |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
bzr renames and deletes a directory over FTP to cause an unlock. If the server does not process these commands in an immediate, atomic manner, then attempting to rename a new lock directory into place will fail.
During bzr push to a new branch bzr locks the repository twice:
- creating it
- pushing the new content
With a server that doesn't process deletes immediately these two behaviours combine to give the user a confusing lock held error - with the user as the lock holder, and the current bzr process id.
This should eventually right itself when the server does process the requested deletes.
As it is on II6 FTP server, CHMOD errors may be reported as well.
Debugging has shown that the server is not processing either RENAME correctly from the locks held directory to the unlocked state (which is a temporary directory name) or the RM of the lock/held file.
The observed symptoms at the FTP level are:
the rename is reported successful.
deleting the new path of the temp/info and the temp directory succeeds
but the directory is still present when we check later and the contents of the info file can s till be read from lock/held.
Various tests have been done, including reading-back from the held/info file to make sure it still exists, and these have shown some very inconsistent behaviour. The most recent test showed this behaviour:
43.900 FTP rename: /texdotnet/
44.927 FTP get: /texdotnet/
45.220 FTP get: /texdotnet/
45.499 FTP rename: /texdotnet/
That is, this FTP server lets bzr rename a directory, then read a file from within that old directory path twice, but when we try to rename the directory again it errors.
It looks like some sort of fs caching/locking is occuring in the server. We have speculated about virus scanners and cluster file systems but have no concrete details from the FTP server operator, who insist that the server is operating 'normally'.
RFC 959 section 4.2 specifies that incomplete operations should send a 1xx Positive Preliminary Reply - the server is not doing that, rather it is sending a 2xx - Positive completion reply. This is clearly in violation of the FTP specification.
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)
summary: |
- Cannot push to Windows FTP server (Microsoft FTP Service IIS6) + unlock fails to unlock over FTP with Windows FTP server (Microsoft FTP + Service IIS6) |
tags: | added: ftp lock |
summary: |
- unlock fails to unlock over FTP with Windows FTP server (Microsoft FTP - Service IIS6) + unlock fails to unlock over FTP with Windows IIS6 FTP server which keeps + files after delete |
description: | updated |
description: | updated |
tags: | added: check-for-breezy |
Changed in brz: | |
status: | New → Won't Fix |
tags: | removed: check-for-breezy |
So we did a log of this on IRC with -Dtransport. This shows the held->tmp rename succeeding, a nd the subsequent
rm tmp/info
rmd tmp
succeeding too, but the lock remains in place.
my theory is a virus scanner or some such interfering.
Some things we can do to narrow it down:
-add a read-back after the rename to make sure it does rename away successfully.
Something we did:
-tried a 2s delay before the rename, but this didn't appear to have any effect.