ftpd 2.0.1 → 2.0.2

data/features/ftp_server/name_list_tls.feature

@@ -1,30 +0,0 @@
-Feature: Name List TLS
-
-  As a client
-  I want to securely list file names
-  So that I can see what file to transfer
-  And nobody else can
-
-  Background:
-    Given the test server has TLS mode "explicit"
-    And the test server is started
-
-  Scenario: Active
-    Given a successful login with explicit TLS
-    And the server has file "foo"
-    And the server has file "bar"
-    And the client is in active mode
-    When the client successfully name-lists the directory
-    Then the file list should be in short form
-    And the file list should contain "foo"
-    And the file list should contain "bar"
-
-  Scenario: Passive
-    Given a successful login with explicit TLS
-    And the server has file "foo"
-    And the server has file "bar"
-    And the client is in passive mode
-    When the client successfully name-lists the directory
-    Then the file list should be in short form
-    And the file list should contain "foo"
-    And the file list should contain "bar"

data/features/ftp_server/noop.feature

@@ -1,17 +0,0 @@
-Feature: No Operation
-
-  As a client
-  I want to keep the connection alive
-  So that I don't have to log in so often
-
-  Background:
-    Given the test server is started
-
-  Scenario: NOP
-    Given a successful connection
-    Then the client successfully does nothing
-
-  Scenario: With a parameter
-    Given a successful connection
-    When the client does nothing with a parameter
-    Then the server returns a syntax error

data/features/ftp_server/options.feature

@@ -1,17 +0,0 @@
-Feature: Options
-
-  As a client
-  I want to know set options
-  To tailor the server's behavior
-
-  Background:
-    Given the test server is started
-    And the client connects
-
-  Scenario: No argument
-    When the client sends "OPTS"
-    Then the server returns a syntax error
-
-  Scenario: Unknown option command
-    When the client sets option "ABC"
-    Then the server returns a bad option error

data/features/ftp_server/pasv.feature

@@ -1,30 +0,0 @@
-Feature: PASV
-
-  As a programmer
-  I want good error messages
-  So that I can correct problems
-
-  Scenario: No argument
-    Given the test server is started
-    Given a successful login
-    Then the client successfully sends "PASV"
-
-  Scenario: After "EPSV ALL"
-    Given the test server is started
-    Given a successful login
-    Given the client successfully sends "EPSV ALL"
-    When the client sends "PASV"
-    Then the server sends a not allowed after epsv all error
-
-  Scenario: Not logged in
-    Given the test server is started
-    Given a successful connection
-    When the client sends "EPSV"
-    Then the server returns a not logged in error
-
-  Scenario: Configured with NAT IP
-    Given the test server has a NAT IP of 10.1.2.3
-    Given the test server is started
-    And a successful login
-    When the client successfully sends "PASV"
-    Then the server advertises passive IP 10.1.2.3

data/features/ftp_server/port.feature

@@ -1,49 +0,0 @@
-Feature: PORT
-
-  As a programmer
-  I want good error messages
-  So that I can correct problems
-
-  Background:
-    Given the test server is started
-
-  Scenario: Port 1024
-    Given a successful login
-    Then the client successfully sends "PORT 1,2,3,4,4,0"
-
-  Scenario: Port 1023; low ports disallowed
-    Given the test server disallows low data ports
-    And a successful login
-    When the client sends "PORT 1,2,3,4,3,255"
-    Then the server returns an unimplemented parameter error
-
-  Scenario: Port 1023; low ports allowed
-    Given the test server allows low data ports
-    And a successful login
-    Then the client successfully sends "PORT 1,2,3,4,3,255"
-
-  Scenario: Not logged in
-    Given a successful connection
-    When the client sends PORT "1,2,3,4,5,6"
-    Then the server returns a not logged in error
-
-  Scenario: Incorrect number of bytes
-    Given a successful login
-    When the client sends PORT "1,2,3,4,5"
-    Then the server returns a syntax error
-
-  Scenario: Ill formatted byte
-    Given a successful login
-    When the client sends PORT "1,2,3,4,5,0006"
-    Then the server returns a syntax error
-
-  Scenario: Byte out of range
-    Given a successful login
-    When the client sends PORT "1,2,3,4,5,256"
-    Then the server returns a syntax error
-
-  Scenario: After "EPSV ALL"
-    Given a successful login
-    Given the client successfully sends "EPSV ALL"
-    When the client sends "PORT 1,2,3,4,4,0"
-    Then the server sends a not allowed after epsv all error

data/features/ftp_server/put.feature

@@ -1,79 +0,0 @@
-Feature: Put
-
-  As a client
-  I want to upload a file
-  So that someone else can have it
-
-  Background:
-    Given the test server is started
-
-  Scenario: ASCII file with *nix line endings
-    Given a successful login
-    And the client has file "ascii_unix"
-    When the client successfully puts text "ascii_unix"
-    Then the remote file "ascii_unix" should match the local file
-    And the remote file "ascii_unix" should have unix line endings
-
-  Scenario: ASCII file with windows line endings
-    Given a successful login
-    And the client has file "ascii_windows"
-    When the client successfully puts text "ascii_windows"
-    Then the remote file "ascii_windows" should match the local file
-    And the remote file "ascii_windows" should have unix line endings
-
-  Scenario: Binary file
-    Given a successful login
-    And the client has file "binary"
-    When the client successfully puts binary "binary"
-    Then the remote file "binary" should exactly match the local file
-
-  Scenario: Passive
-    Given a successful login
-    And the client has file "ascii_unix"
-    And the client is in passive mode
-    When the client successfully puts text "ascii_unix"
-    Then the remote file "ascii_unix" should match the local file
-
-  Scenario: Non-root working directory
-    Given a successful login
-    And the client has file "ascii_unix"
-    And the server has directory "foo"
-    And the client successfully cd's to "foo"
-    When the client successfully puts text "ascii_unix"
-    Then the remote file "foo/ascii_unix" should match the local file
-
-  Scenario: Access denied
-    Given a successful login
-    And the client has file "forbidden"
-    When the client puts text "forbidden"
-    Then the server returns an access denied error
-
-  Scenario: Missing directory
-    Given a successful login
-    And the client has file "bar"
-    When the client puts text "foo/bar"
-    Then the server returns a not found error
-
-  Scenario: Not logged in
-    Given a successful connection
-    And the client has file "foo"
-    When the client puts text "foo"
-    Then the server returns a not logged in error
-
-  Scenario: Missing path
-    Given a successful login
-    When the client puts with no path
-    Then the server returns a syntax error
-
-  Scenario: File system error
-    Given a successful login
-    And the client has file "unable"
-    When the client puts text "unable"
-    Then the server returns an action not taken error
-
-  Scenario: Write not enabled
-    Given the test server lacks write
-    And a successful login
-    And the client has file "foo"
-    When the client puts text "foo"
-    Then the server returns an unimplemented command error

data/features/ftp_server/put_tls.feature

@@ -1,23 +0,0 @@
-Feature: Put TLS
-
-  As a client
-  I want to put a file securely
-  So that nobody can intercept it
-
-  Background:
-    Given the test server has TLS mode "explicit"
-    And the test server is started
-
-  Scenario: Active
-    Given a successful login with explicit TLS
-    And the client has file "ascii_unix"
-    And the client is in active mode
-    When the client successfully puts text "ascii_unix"
-    Then the remote file "ascii_unix" should match the local file
-
-  Scenario: Passive
-    Given a successful login with explicit TLS
-    And the client has file "ascii_unix"
-    And the client is in passive mode
-    When the client successfully puts text "ascii_unix"
-    Then the remote file "ascii_unix" should match the local file

data/features/ftp_server/put_unique.feature

@@ -1,56 +0,0 @@
-Feature: Put Unique
-
-  As a client
-  I want to upload a file with a unique name
-  So that it will not overwrite an existing file
-
-  Background:
-    Given the test server is started
-
-  Scenario: File does not exist
-    Given a successful login
-    And the client has file "foo"
-    When the client successfully stores unique "foo"
-    Then the server should have a file with the contents of "foo"
-
-  Scenario: Suggest name
-    Given a successful login
-    And the client has file "foo"
-    When the client successfully stores unique "foo" to "bar"
-    Then the server should have a file with the contents of "foo"
-    And the server should have 1 file with "bar" in the name
-
-  Scenario: Suggested name exists
-    Given a successful login
-    And the client has file "foo"
-    And the server has file "bar"
-    When the client successfully stores unique "foo" to "bar"
-    Then the server should have a file with the contents of "foo"
-    Then the server should have a file with the contents of "bar"
-    And the server should have 2 files with "bar" in the name
-
-  Scenario: Non-root working directory
-    Given a successful login
-    And the client has file "bar"
-    And the server has directory "foo"
-    And the client successfully cd's to "foo"
-    When the client successfully stores unique "bar" to "bar"
-    Then the remote file "foo/bar" should match the local file
-
-  Scenario: Missing directory
-    Given a successful login
-    And the client has file "bar"
-    When the client stores unique "bar" to "foo/bar"
-    Then the server returns a not found error
-
-  Scenario: Not logged in
-    Given a successful connection
-    When the client sends "STOU"
-    Then the server returns a not logged in error
-
-  Scenario: Write not enabled
-    Given the test server lacks write
-    And a successful login
-    And the client has file "foo"
-    When the client stores unique "foo"
-    Then the server returns an unimplemented command error

data/features/ftp_server/quit.feature

@@ -1,23 +0,0 @@
-Feature: Quit
-
-  As a client
-  In order to free up resources
-  I want to close the connection
-
-  Background:
-    Given the test server is started
-
-  Scenario: Logged in
-    Given a successful login
-    When the client successfully quits
-    Then the client should not be logged in
-
-  Scenario: With a parameter
-    Given a successful connection
-    When the client quits with a parameter
-    Then the server returns a syntax error
-
-  Scenario: Not logged in
-    Given a successful connection
-    When the client quits
-    Then the server returns a not logged in error

data/features/ftp_server/reinitialize.feature

@@ -1,13 +0,0 @@
-Feature: Reinitialize
-
-  As a client
-  I want to know this command is not supported
-  So that I can avoid using it
-
-  Background:
-    Given the test server is started
-
-  Scenario: Unimplemented
-    Given a successful connection
-    When the client sends command "REIN"
-    Then the server returns an unimplemented command error

data/features/ftp_server/rename.feature

@@ -1,97 +0,0 @@
-Feature: Rename
-
-  As a client
-  I want to rename a file
-  To correct an improper name
-
-  Background:
-    Given the test server is started
-
-  Scenario: Rename
-    Given a successful login
-    And the server has file "foo"
-    When the client successfully renames "foo" to "bar"
-    Then the server should not have file "foo"
-    And the server should have file "bar"
-
-  Scenario: Move
-    Given a successful login
-    And the server has file "foo/bar"
-    And the server has directory "baz"
-    When the client successfully renames "foo/bar" to "baz/qux"
-    Then the server should not have file "foo/bar"
-    And the server should have file "baz/qux"
-
-  Scenario: Non-root working directory
-    Given a successful login
-    And the server has file "foo/bar"
-    And the client successfully cd's to "foo"
-    When the client successfully renames "bar" to "baz"
-    Then the server should not have file "foo/bar"
-    Then the server should have file "foo/baz"
-
-  Scenario: Access denied (source)
-    Given a successful login
-    When the client renames "forbidden" to "foo"
-    Then the server returns an access denied error
-
-  Scenario: Access denied (destination)
-    Given a successful login
-    And the server has file "foo"
-    When the client renames "foo" to "forbidden"
-    Then the server returns an access denied error
-
-  Scenario: Source missing
-    Given a successful login
-    When the client renames "foo" to "bar"
-    Then the server returns a not found error
-
-  Scenario: Destination exists
-    Given a successful login
-    And the server has file "foo"
-    And the server has file "bar"
-    When the client renames "foo" to "bar"
-    Then the server returns an already exists error
-
-  Scenario: Not logged in (RNFR)
-    Given a successful connection
-    When the client sends "RNFR foo"
-    Then the server returns a not logged in error
-
-  Scenario: Not logged in (RNTO)
-    Given a successful connection
-    When the client sends "RNTO foo"
-    # Although the RNTO command checks for logged in, sequence error
-    # gets triggered first.
-    Then the server returns a bad sequence error
-
-  Scenario: Missing path (RNFR)
-    Given a successful login
-    When the client sends "RNFR"
-    Then the server returns a syntax error
-
-  Scenario: Missing path (RNTO)
-    Given a successful login
-    And the server has file "foo"
-    And the client successfully sends "RNFR foo"
-    When the client sends "RNTO"
-    Then the server returns a syntax error
-
-  Scenario: Rename not enabled
-    Given the test server lacks rename
-    And a successful login
-    And the server has file "foo"
-    When the client renames "foo" to "bar"
-    Then the server returns an unimplemented command error
-
-  Scenario: RNTO without RNFR
-    Given a successful login
-    When the client sends "RNTO bar"
-    Then the server returns a bad sequence error
-
-  Scenario: RNFR not followed by RNTO
-    Given a successful login
-    And the server has file "foo"
-    And the client sends "RNFR foo"
-    When the client sends "NOOP"
-    Then the server returns a bad sequence error