Feature Request: Add Mock File System Support to Fossil Mock

[dreamer-coding]

Is your feature request related to a problem? Please describe.

Testing file system interactions (file creation, reading, writing, and deletion) often requires creating temporary files or manipulating the actual file system, which can be error-prone and slow. Simulating various scenarios (e.g., file not found, permission denied, disk full) is difficult without a controlled mock file system.

Describe the solution you’d like

Introduce a mockable file system API in Fossil Mock to simulate file operations and enable controlled testing of file-related functionality.

Features:
1. File System Operations
• Mock implementations for standard file operations:
• File creation (fopen, fclose)
• Reading (fread, fgets)
• Writing (fwrite, fputs)
• Deletion (remove)
• Metadata queries (e.g., stat, fstat)
2. Mock Behavior
• Simulate file system errors:
• File not found (ENOENT)
• Permission denied (EACCES)
• Disk full (ENOSPC)
• Simulate custom file contents and metadata (e.g., size, modification times).
3. In-Memory File System
• Store files and directories in memory for fast and isolated testing.
• Support hierarchical directory structures.
• Provide APIs for creating, modifying, and deleting mock files/directories.
4. Customization Options
• Allow developers to define custom behavior for specific file paths or operations.
• Inject mock functions dynamically to override standard library calls.
5. Mock Configuration
• Configure mock environments via Fossil Mock’s setup API.
• Include options for default file system state and error injection.
6. Integration with Fossil Test
• Provide seamless integration for testing file-related operations in Fossil Test.
• Allow file-related test cases to include mock file system setups and validations.

Describe alternatives you’ve considered
1. Temporary Files/Directories:
Using real files and directories created during test setup and cleaned up afterward. While functional, this approach can be slow, error-prone, and limited in simulating edge cases (e.g., disk full).
2. Third-Party Libraries:
Using external mock file system libraries. This introduces dependencies and requires integration effort, reducing the portability of Fossil Mock.

Additional Context
• Use Cases:
• Testing applications that read/write configuration files.
• Simulating file-related errors to ensure robust error handling.
• Validating operations like file backup, file search, and directory traversal.
• Implementation Notes:
• Provide stubs for common file operations (fopen, fread, etc.) and redirect them to the mock system when active.
• Maintain compatibility with standard library functions when the mock system is disabled.
• Store mock file data and metadata in memory, with APIs to query and manipulate it.
• Include a cleanup function to reset the mock file system after each test.
• Reporting and Debugging:
• Include tools to inspect the current state of the mock file system.
• Allow developers to log all file system interactions for debugging.