Do not fail Mkdir when the server does not name the directory - #72
Open
christhomas wants to merge 1 commit into
Open
Do not fail Mkdir when the server does not name the directory#72christhomas wants to merge 1 commit into
christhomas wants to merge 1 commit into
Conversation
A server answering MKD with 257 has created the directory. RFC 959 asks it to echo the pathname in quotes as well, and not every server does — proftpd and several embedded servers answer a bare "257 Directory created". Mkdir treated that as a parse failure and returned an error, so the caller saw a failure for a directory that now exists. Retrying then reports that it already does, which is a confusing place to end up from a call that worked. A reply without a name is a success whose name cannot be read, not a failure. Mkdir now answers with the path it was asked for. Getwd is left alone deliberately. It calls the same parser, but there the pathname *is* the answer — a PWD reply without one has nothing to return, so failing is correct. The added parser test pins that distinction so a later change cannot relax both at once. Found by a filesystem driver whose test server sends exactly this reply: every Mkdir failed while every directory was created.
christhomas
force-pushed
the
cth/mkdir-tolerates-unnamed-reply
branch
from
August 26, 2026 11:22
fc57f6e to
a85f244
Compare
This was referenced Aug 26, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A server answering
MKDwith 257 has created the directory. RFC 959 asks it to echo the pathname in quotes as well, and not every server does — proftpd and several embedded servers answer a bare257 Directory created.Mkdirtreats that as a parse failure and returns an error, so the caller sees a failure for a directory that now exists. Retrying then reports that it already does, which is a confusing place to end up from a call that worked.A reply without a name is a success whose name cannot be read, not a failure.
Mkdirnow answers with the path it was asked for.Getwdis deliberately unchanged. It calls the sameextractDirName, but there the pathname is the answer — aPWDreply without one has nothing to return, so failing is correct. The added parser test pins that distinction.How it turned up
An FTP filesystem driver, against a test server that sends exactly this reply. Every
Mkdirfailed while every directory was created.Tests
TestExtractDirNameRejectsAReplyWithoutAName— needs no server, pins the parser (including that a well-formed reply still parses)TestMkdirAcceptsReplyWithoutAName— stubs the reply and assertsMkdircarries onSeparate from #71 and does not depend on it; happy to rebase whichever lands second.