Open EmiliosRichards opened 7 months ago
Design decision made to keep CLI UI Separate, good practice, easier to maintain, keeps the logic distinct, application remains modular.
Edited unreachable code and provided a initial check for creating new files and directories.
Whilst refreshing code (Refactoring from flag to direct), adjusting copy to only refresh when a copy is made into the same directory, also implementing a file_copy function to create copies of files without just replacing existing file instance.
Advantages of Direct Updates Accuracy: Ensures that the internal state of your application is always in sync with the filesystem without needing to remember to check or reset a flag.
Simplicity: Reduces the complexity of your code by eliminating the need to manage and check the state of a flag across different parts of your code.
Debugging and Maintenance: Easier to debug and maintain as you don't have to trace when and where the flag is set or cleared. It's clear from the method that modifies the filesystem that it updates the state immediately afterward.
Performance Considerations: While this might seem like it could degrade performance due to frequent disk reads, for most use cases where the directory contents aren't excessively large, this should not be a significant issue. If performance becomes a concern, you might then consider optimizations such as caching or more controlled refresh strategies.
Refreshing File List on Copy to Another Directory: If you copy a file to another directory that the FileManager is not monitoring, then a refresh in the current directory is not necessary, as the contents of the monitored directory have not changed. You are correct about this.
Copying Within the Same Directory: When a file is copied within the same directory using the same filename, it indeed does nothing as it essentially creates a duplicate with the same name, overwriting the existing file. As you pointed out, this operation is redundant and potentially destructive without adding any value.
To omit directory file size check and location space availability. Seemed to be out of the scope of this project due to the additional features that would be required. IE Progress feedback, logging states, Asynchronous checks and added impact on performance.
Can be found in *FMS latest update ReadMe + Code plan
Not going to implement Pathlib:
If you find the syntax and features of pathlib appealing and they fit well with your project's needs, it is definitely worth adopting. It can lead to cleaner, more Pythonic code for handling filesystem paths and operations. However, if your project already extensively uses os and the refactor overhead is significant, you might choose to integrate pathlib gradually or only in parts of the project where its benefits are most pronounced.
FMS Latest Read + codeplan branches 3 - 4
Need to jump inside the code in order to refine further. Cant rely on AI at this point.
Summary of the Change: Universal Error Feedback: By standardizing the error messages, every user action that results in an exception will receive a clear and descriptive error message that helps them understand the issue without additional context provided by verbose output. Reduced Complexity: Removing the conditionality of verbose mode from error handling simplifies the codebase. This makes it easier to maintain and less prone to bugs related to different modes handling errors differently. Improved Logging: Despite the simplification in how messages are displayed to the user, the logging functionality remains robust, ensuring that all errors are logged with sufficient detail for diagnostic purposes.
Verbose Mode Utility: With these changes, the verbose mode can now be focused more on providing additional operational details (like showing the steps being taken by the system during an operation) rather than being a requirement for understanding error messages. This makes verbose mode a tool for deeper insights rather than essential for basic error comprehension. User Testing: It's always a good idea to test these changes with real users or through user scenarios to ensure that the messages are not only clear but also actionable. You might find that while some errors are self-explanatory, others might require additional instructions or suggestions on how to resolve the issue. Further Refinement: Depending on user feedback and your own observations, you might want to refine the wording, detail level, or even the format of the error messages to make them as helpful as possible.
Good additions:
Felt like it was overkill for the type of project this is supposed to be. Added to future considerations, yet making an entirely new GUI may prove more appropriate.
same goes for :
Interactive User Experience: You can improve the interactive aspect of your CLI by allowing users to navigate back to previous menus or repeat the last command without re-entering it. This can make the user experience smoother and more efficient.
Need to download -
conda install -c conda-forge pyreadline
add to yaml file
Current Focuses Include:
Fixed verbosity by ensuring to pass the flag to the filemanager methods
def create_file(self): file_name = self.get_input('Enter the name of the file you would like to create: ') result = self.file_manager.create_file(file_name, verbose=self.verbose) print(result) self.display_menu()
Used os.system clear terminal function for its easy integration.
Using os.system() has several implications, particularly in the areas of security and performance:
Security Risks:
Shell Injection: The most significant security concern with os.system() is the risk of shell injection. This occurs when the command passed to os.system() includes unsanitized input from an external source, potentially allowing an attacker to execute arbitrary commands on the shell. This can lead to unauthorized access, data leakage, and other security breaches. Escaping Problems: Properly escaping characters in the commands passed to os.system() can be error-prone and challenging, especially when user input is involved. Performance Overhead:
Creating a New Process: Each call to os.system() starts a new shell process, which can be a heavy operation compared to other methods of executing commands that don’t involve starting a shell. This can lead to reduced performance, especially in a loop or a highly repetitive part of the code. Portability Concerns:
While os.system() generally works across different platforms, the actual commands you pass to it (like cls or clear) may not be portable. This means that a command that works on Windows might not work on Unix/Linux systems and vice versa.
Could Include awareness about additional security requirements such as path traversal attacks (Out of Scope)
Your sanitization function is a good start for security. Consider additional security measures to prevent other potential vulnerabilities, such as symbolic link attacks or race conditions.
Could mention need for dictionary adjustments, could mention need to make more confinement, many features needed, including gui. but as a simple project sufficient. So much more i could do to make it a good application.
Had the start of a readline feature, deffo worth improving, and has room for expansion. The code is concise, modular, maintainable and designed for future development
Design Point
Adjusting Update self.files to reduce wastage of resources. Adding a Flag system. ETC