A .NET 10 C# console application that manages file count in a directory by removing the oldest files when the count exceeds a specified threshold.

• Cross-platform: Targets Windows (x64) and Linux (ARM64)
• Asynchronous Operation: Efficient file operations using async/await
• Comprehensive Logging: Platform-compatible logging to local directories
  • Windows: %LOCALAPPDATA%\FileLimitService\Logs
  • Linux: /var/log/FileLimitService or ~/.local/share/FileLimitService/logs
• Detailed Metrics: Logs include file counts, age statistics, and deletion details

# Using command-line arguments
FileLimitService <target-directory> <max-file-count> [noui]

# Using configuration file
FileLimitService --config <config-file-path> [noui]

• target-directory: Path to the directory to monitor and clean
• max-file-count: Maximum number of files to keep in the directory (non-negative integer)
• --config: Path to JSON configuration file
• noui: (Optional) Suppress all console output while still logging to file

# Keep only 100 files in the logs directory
FileLimitService /var/log/myapp 100

# On Windows, keep 50 files in a backup directory
FileLimitService "C:\Backups\Daily" 50

# Run silently without console output (useful for automated jobs)
FileLimitService /var/log/myapp 100 noui

# Use configuration file
FileLimitService --config /etc/FileLimitService/config.json

Create a JSON configuration file:

{
  "targetDirectory": "/var/log/myapp",
  "maxFileCount": 100,
  "enableLogging": true
}

• targetDirectory: Path to monitor (required)
• maxFileCount: Maximum files to keep (required, non-negative)
• enableLogging: Enable console/file logging (optional, default: true)

dotnet build FileLimitService.slnx

dotnet publish FileLimitService/FileLimitService.csproj -c Release -r win-x64 --self-contained false -o publish/win-x64

dotnet publish FileLimitService/FileLimitService.csproj -c Release -r linux-arm64 --self-contained false -o publish/linux-arm64

To download and use pre-built binaries from GitHub Releases:

# Download the latest release for Linux ARM64
wget https://github.com/nojronatron/file-limit-service/releases/latest/download/FileLimitService-linux-arm64.zip

# Extract the archive
unzip FileLimitService-linux-arm64.zip

# Make the binary executable
chmod +x FileLimitService

# Run the service
./FileLimitService /path/to/target 100

The release archive includes:

• FileLimitService - The main executable
• systemd/ - Systemd service and timer unit files
• install-system.sh - System-wide installation script

For automated deployment, consider setting up a systemd service, cron job, or Windows Task Scheduler to run the service on a schedule.

FileLimitService can run as a systemd service with automatic timer-based execution.

1. Download and extract the latest release:

   wget https://github.com/nojronatron/file-limit-service/releases/latest/download/FileLimitService-linux-arm64.zip
   unzip FileLimitService-linux-arm64.zip

2. Run the installation script:

   sudo ./install-system.sh

3. Edit the configuration file:

   sudo nano /etc/FileLimitService/config.json

   Update targetDirectory and maxFileCount for your needs.

4. Test manually before enabling:

   /usr/local/bin/FileLimitService --config /etc/FileLimitService/config.json

5. Enable and start the timer:

   sudo systemctl enable filelimitservice.timer
   sudo systemctl start filelimitservice.timer

# Check timer status
sudo systemctl status filelimitservice.timer

# Check service execution logs
sudo journalctl -u filelimitservice -f

# Stop the timer
sudo systemctl stop filelimitservice.timer

# Disable automatic startup
sudo systemctl disable filelimitservice.timer

# Manually trigger cleanup now
sudo systemctl start filelimitservice.service

The default timer runs every hour. To customize:

# Edit the timer unit
sudo systemctl edit filelimitservice.timer

Add an override in the editor:

[Timer]
# Run every 2 hours
OnUnitActiveSec=2h

Timer interval options:

• 1h = Every hour
• 2h = Every 2 hours
• 12h = Twice daily
• 24h or 1d = Daily
• 168h or 7d = Weekly

Save and reload:

sudo systemctl daemon-reload
sudo systemctl restart filelimitservice.timer

dotnet test

1. Validation: Checks that the target directory exists and arguments are valid
2. Enumeration: Gets all files in the target directory
3. Analysis: Calculates current file count, oldest and newest file ages
4. Cleanup: If file count exceeds threshold, deletes oldest files first
5. Logging: Records all actions with timestamps to platform-specific log directory

The service logs the following information:

• Target directory and maximum file count parameters
• Current file count before cleanup
• Oldest and newest file ages (in days)
• Each deleted file with its age
• Total count of deleted files
• Final file count after cleanup

Logs are written to both the console and a timestamped log file.

The service can be automated using:

• Systemd: Timer-based service units (Linux) - See above
• Cron: Scheduled jobs (Linux/Unix)
• Task Scheduler: Windows automation

# Run every day at 2 AM to keep max 1000 files (silent mode)
0 2 * * * /path/to/FileLimitService /var/log/myapp 1000 noui

# Or use config file
0 2 * * * /usr/local/bin/FileLimitService --config /etc/FileLimitService/config.json noui

Enable users to run FileLimitService without sudo for personal directories:

• Install to ~/.local/bin/ with install-user.sh script
• User systemd services in ~/.config/systemd/user/
• Config files in ~/.config/FileLimitService/config.json
• Use loginctl enable-linger for background operation after logout
• Ideal for cleaning ~/Downloads, ~/tmp, and other user-owned directories

Benefits:

• No root privileges required
• Each user manages their own cleanup rules
• Isolated from system-wide configuration

Limitations:

• Cannot access system directories like /var/log
• Service stops when user logs out (unless linger enabled)

Monitor multiple directories from a single configuration:

Config schema:

{
  "targets": [
    {"path": "/var/log/app1", "maxFiles": 100},
    {"path": "/var/log/app2", "maxFiles": 50},
    {"path": "/tmp/cache", "maxFiles": 200}
  ],
  "enableLogging": true
}

Implementation considerations:

• Single service execution processes all targets sequentially
• Individual target failures don't stop processing remaining targets
• Aggregate logging with per-target metrics
• Backward compatible with single-directory config format

Use cases:

• Centralized cleanup management for multiple applications
• Different retention policies per directory
• Reduced systemd service overhead (one timer instead of many)

• .NET 10 Runtime or SDK
• Read/write permissions on target directory
• Write permissions on log directory

See LICENSE file for details.