Brittbot

Upgrading from Data Center Tech to Software Engineer

A rack of servers in a data center with an empty thought bubble to the side of the rack of servers.

Using Gemini To Find Potential Bugs In My Code

I’m using Gemini to find potential bugs in my code because it works so well. I used it while creating my last project: Easy Home Directory Backup. After it worked out so well, I’m going to continue using it for all my future projects.

Why Am I Using Gemini To Find Potential Bugs?

I can’t think of all the potential issues a user could run into while using my program. Oh yes, I can think of the big ones like validating user input, but there are other issues lurking that I’m missing.

So I turned to Gemini and entered this prompt:

Hey Gemini, I'm building a backup program that will run in the terminal (CLI) just for Linux distros that uses rsync to back up the currently-signed in user's Home Directory to a backup device. I'm building this with Python. The user supplies the path to the backup device. What are some potential issues a user can run into using this program?

I wanted to give the Large Language Model (LLM) that background information so it could form a good answer. Then I put my question last so the LLM knew what I wanted. I’ve tried putting questions in the middle of the prompt, and that works sometimes, but more often than not I don’t get the greatest replies.

Speaking of replies, I got a lengthy one. I’ll break it down in sections:

Potential Issues and Considerations for Your Backup Program

Here are some potential issues a user might encounter when using your Python-based rsync backup script:

1. Incorrect Backup Device Path:

* Permissions: Ensure the user has read-write permissions to the backup device.
* Device Mount: Verify the device is properly mounted and accessible.
* Device Format: Check the device's file system (e.g., ext4, NTFS, FAT32) and its compatibility with rsync.

Gemini correctly pointed out that a user could provide a backup device that doesn’t have read/write permissions. Without validating that my program could crash. Or it could run and not do anything. Next, the user could try to use a backup device that isn’t mounted, or has non-Linux compatible file system. With this information in hand I added a TODO in my notebook to figure out a solution to these issues.

2. Rsync Errors and Failures:

* Network Issues: If the backup device is network-mounted, intermittent network connectivity can cause failures.
* Disk Space: Insufficient space on the backup device can lead to incomplete backups.
* File Access Permissions: If files or directories on the source or destination have restrictive permissions, rsync might fail.
* File System Errors: Corrupted file systems or disk errors can disrupt the backup process.

This section is all about various rsync errors users could run into. I skipped over the information about network issues because my program is strictly for local storage usage, and I inform the user of that. However, disk space is a huge potential issue I didn’t think of. Or course checking for ample free space to contain the Home Directory backup was vital, so I created a TODO for that. Regarding the last two bullet points I decided to check for basic file access permissions, but not for file system errors. The user will need to do the latter.

3. Script Execution and Permissions:

* Script Permissions: The script must have executable permissions for the user.
* User Privileges: The user might need elevated privileges (e.g., sudo) to access certain directories or devices.
* Background Execution: If the script is intended to run in the background, ensure proper configuration for logging and error handling.

These issues I skipped over. Since I’m targeting experienced Linux users with my backup program they should know how to make the script executable. However, I don’t think that’s needed from my testing. The other two bullet points don’t apply to my program since it doesn’t require elevated privileges or runs in the background.

4. Backup Strategy and Retention:

* Incremental Backups: Consider implementing incremental backups to reduce backup time and storage usage.
* Backup Rotation: Implement a strategy to rotate backup files to prevent excessive disk usage.
* Backup Verification: Regularly verify the integrity of backups to ensure data recoverability.

Frankly, I skipped over this section since I wasn’t going to implement any of these features in my program.

5. User Experience and Error Handling:

* Clear Error Messages: Provide informative error messages to help users troubleshoot issues.
* Progress Indicators: Display progress indicators to keep users informed about the backup process.
* Logging: Log detailed information about the backup process for troubleshooting and analysis.
* User Input Validation: Validate user input to prevent invalid paths and other errors.

These suggestions was what I was looking for, and it should’ve been the first thing listed instead of the last. I added all of these as TODOs in my notebook.

Now I hope you see why I will continue using Gemini to find potential bugs in my code.