Protected paths: what FTP by Zaweba will not let you break
FTP by Zaweba blocks moving, renaming or deleting files that break a site, such as .htaccess, wp-config.php and .env. Here is what is covered and why.

Some files on a web server are tiny, dull to look at, and holding the whole site up. Rename .htaccess and the pretty addresses stop working. Delete wp-config.php and a WordPress site shows an error instead of a page. Move a cPanel folder and email or certificates can stop working for the whole account. FTP by Zaweba keeps a list of these items and blocks the actions that would damage them.
What is protected
The list covers items that break a site or a hosting account if they are moved, renamed, re-permissioned or deleted. It includes .htaccess, wp-config.php and .env, the .well-known/ folder (used by certificates and other checks) and cgi-bin/. It includes the web root itself, because moving or deleting it takes the whole site with it. And it includes cPanel folders such as mail/, etc/, ssl/ and logs/, which hold things that belong to the hosting account rather than the website.
Those are the kinds of files that clean-up tools catch by accident. They look odd, their names start with a dot or mean nothing at first glance, and in a list sorted by size or date they appear among junk.
What protection means in practice
Protected items are blocked from the actions that would harm them. When a batch includes one, the confirmation lists it as left out, so the rest of the job goes ahead and you can see exactly what was skipped. Bulk rename leaves protected items out too.
Folders that merely contain a protected item are allowed, but the confirmation says so. That matters because a folder like a theme or an app directory might hold its own .htaccess. You can still work with it; the warning just makes sure you know what is inside before you act.
The Disk option
Each site has a Disk option in Site Manager to allow protected paths to be changed. It exists for the rare case where you really do need to move or remove one of these items and know exactly why. It is not recommended, and it is a per-site setting rather than a global switch, so turning it on for one site does not loosen the rules on any other.
If you do turn it on, do the job and turn it off again. Leaving it on removes a safety net for every future clean-up on that site.
Why the list is fixed rather than up to you
Lots of tools leave safety entirely to the user, on the reasoning that the user knows best. In practice, the user usually does know best, except for the one moment of distraction that matters. A short, fixed list of the files that almost nobody should touch by accident, applied by default, catches that moment without getting in the way of ordinary work.
It is one piece of a wider approach in FTP by Zaweba. Server deletes can go to a trash. Disk changes are logged and can be undone as a batch. Permission changes that would make things world-writable need an explicit confirmation. Protected paths sit in front of all of that, stopping the worst mistakes before they reach the trash or the log at all.
Good habits
When a confirmation says something was left out, read the name. It tells you something about the folder you were working in. If you were tidying an old copy of a site and its .htaccess was skipped, that may be a hint that the folder is still in use.
If you need to change one of these files, edit it rather than moving or deleting it. Open .htaccess or wp-config.php in the code editor, which colours Apache .htaccess and PHP, make the change, and let the local version history keep the previous copy in case you need it back.
Protected paths will rarely get in your way. When they do, it is worth stopping to think, because that is the moment they were made for.