File-managing server is required to handle multiple clients connecting to it where each client shall work in a directory of their own and with files inaccessible to other users. If a user is already logged in, further requests to log in with that username should be denied. However, the server is only required to be able to handle one service request at a time. Do note that service requests done by different users should not interfere with one [login to view URL] instance, if two users use the command "read_file" but with different files, then subsequent calls done by these users are to handle the specific user's file and not any other file.
Sample directory structure is [login to view URL] is not required for use. Service requests are never to be allowed to traverse outside of a given server structure. The structure can be found here.
Registered users, folders, files, and other implementation data must be saved between sessions! Users created during one session must be usable the next time the server is started, and all folders, files, and data are to be properly accessible.
How the server keeps tab on this structure is up to you; it is strongly recommended that you start this assignment with sitting down and define how the server keeps track of all files.
The server is to be supporting a subset of commands commonly found on UNIX-based systems. These commands are heavily simplified compared to their UNIX counterparts and are the services of the server. Please refer to the table below for the different services that are expected of the server, as well as how they are to be used. If a request of service is conducted with an unknown command or an erroneous input, proper information is to be passed back to the client.
Client is taking a more passive role. When started up, it should present the user with the option to either login or register to the server. These options are to result in requests to the server, and a login is only to be allowed if the username and password matches with the information on the [login to view URL] logged in, the client should have the user's personal folder as starting point to work [login to view URL] user should be able to input any command described for the server. Whenever a command is issued, the client is to send a request to the server and present the result to the user if applicable. The client is also required to save down all commands issued by each [login to view URL] got two commands that they are to directly handle themselves
Testing and Error Handling
You are expected to write tests using asserts as well as either the doctest or unittest module for both the server and the client. It is up to you to decide exactly how many tests that are to be written.
The tests implemented with asserts are to be used for simpler tests, for instance the input to functions.
The tests implemented with the doctest or unittest module are to be clearly documented in a test report. The documentation text must highlight why these tests where chosen, what they test, and how it is tested. This report should not contain code, but be an overview of the reasoning behind the test and how these tests were identified as necessary. The report is also required to contain a section arguing why the number of implemented tests were deemed enough and what areas of the code that are not tested.
A pylint value below 8/10 will result in a failed grade
Your code must be logically divided with clear connections.
Proper docstrings are expected for all classes, functions, and modules.
The logic for the server and client must be divided into different files. Everything cannot be implemented in one file.
All code should be written as clearly and consistently as possible.
All built-in standard modules within Python are allowed to use.