Undoing server changes with the operations log in FTP by Zaweba
The Disk operations log in FTP by Zaweba records every change made on a server, batch by batch, and lets you undo renames, moves, trashing and permissions.
Server changes made over FTP are usually one way. Rename a folder, move a set of files or change their permissions, and if you got it wrong, the only route back is to work out what you did and do the opposite by hand. The Disk view in FTP by Zaweba keeps a record instead, and lets you reverse it.
What the log holds
The operations log lists everything Disk has done on a server, batch by batch. A batch is one job as you asked for it: a bulk rename of forty files, a move of a folder, a permissions change across a tree, a set of tagged files sent to the trash. Grouping by batch matches how you think about your own work. You do not remember the forty individual renames; you remember that you tidied the photo names.
Undo this batch
Renames, moves, trashing and permission changes can each be undone as a batch with Undo this batch. Renamed files get their old names back. Moved files go back where they came from. Trashed items come back from the trash. Permissions return to what they were before.
Undoing a whole batch at once is the important part. A bulk rename that went wrong on two hundred files is just as quick to reverse as one that touched two.
Why batches, and why a log
Most mistakes on a server are discovered a little later, not at the moment they happen. The page loads without its images, a script cannot write its cache, a colleague asks where a folder went. By then you may have done several other things. A log by batch lets you find the job that caused the problem and undo just that, leaving the rest of your work alone.
It also gives you a plain record of what a clean-up actually did. If someone asks what changed on the server this afternoon, the log answers.
How it fits with the other safety nets
The operations log is the safety net for Disk's own actions on the server. Other parts of FTP by Zaweba cover other kinds of mistake. The server trash catches deletes, and the Trash window can restore items exactly where they were. The local version history keeps the previous copy of a file before a Get, Put or save overwrites it. Protected paths block the actions that would break a site before they happen. The link update window, after a rename or move, can fix references in your local site and can itself be undone.
Together, they mean that the bold jobs Disk makes possible (bulk renames, folder moves, permission fixes across a whole tree) are also reversible.
Using it well
When something looks wrong after a Disk session, open the log before doing anything else. Read the batches in order and find the one that matches the symptom. Undo that batch, check the site, and only then decide what to try instead.
If you renamed or moved files and also updated links locally, remember that undoing the server batch puts the files back under their old names, while your local link changes are separate. Undo those too, or the pages will point at the new names that no longer exist.
Mistakes to avoid
Do not undo a batch blindly after other people have worked on the site. If a colleague has since uploaded a file with one of the old names, putting yours back may clash with theirs. A quick look at the server pane, or at Site Activity if the activity log is on, shows whether anything has changed since.
Do not use undo instead of thinking first. Bulk rename and the permissions window both preview or confirm before acting, and a careful read there saves needing the log at all.
But when you do need it, it is there, and that is what makes server work in FTP by Zaweba feel safe enough to actually do.
