Release notes 1.3.1

Moves are now much faster in most common scenarios.

There is a tradeoff between accurate progress reporting and efficient file transfers. Fileside very much erred on the side of the former up until now. 1.3.1 rewrites the algorithm for copying and moving files while resolving conflicts, to allow faster moves in the vast majority of cases.

Even if nothing’s changed on the surface, this release contains a considerable reorganisation under the hood, providing a much better foundation for future enhancements.

Improvements

Faster moves

In order to report progress accurately, and to resolve file conflicts correctly, Fileside used a rather non-optimal algorithm for moving large hierarchies of files up until now.

It used a two-step process. It would first step through every folder within the selection to be moved, querying the size for each file, and add up the total number of files as well as the total size in bytes.

Then it would carry out the actual moving in the same way, by recursing down through each folder, handling potential file conflicts as it went, and moving each file one by one.

While logical enough, this fails to take advantage of the fact that operating systems have a very fast way of moving whole folder hierarchies, as long as both source and destination are on the same drive, through the use of renaming. Renaming one parent folder is much faster than stepping through it and renaming each file contained within.

Of course, this method can only be used as long as we know upfront that there are no file conflicts to handle. However, this is likely to be the most common case in actual usage, so it makes sense to start with this optimistic assumption.

Hence, Fileside now assumes that there will be no conflicts when moving a folder, and attempts to rename the whole folder. Only if a folder with the same name exists in the target, does it step into it, to resolve file conflicts at the next level down. This process is repeated at each deeper level, so that further nested subfolders are also renamed wholesale, unless there is a conflict.

While this massively speeds things up in the common case, it can lead to some wonky progress reporting when merging folders. Due to our initial optimistic assumption, we skip the step of adding up all the sizes beforehand. But if we find a conflict, we then have to increase the total number of items to be transferred. This can lead to the progress bar apparently moving backwards when many conflicted folders are discovered as we go. But I think that’s a price most people would be willing to pay for a faster move.

Allow undoing a failed transfer

If a large transfer fails somewhere in the middle, it is now possible to undo the partial work that did get completed. This can come in handy for backing out of a complicated merge.

Bug fixes

Dangling symlinks handled properly

Symlinks that point to a target file or directory that has since been removed could cause some trouble in previous versions. They can now be copied and moved without error.

Allow copying symlinks to mapped network drives on Windows

Windows does not allow creating symlinks on mapped network drives. Fileside would previously fail here. Now it will fall back to copying the target file that the symlink references instead.

Allow deleting read-only folders on Windows

Explorer allows deletion of folders with the read-only attribute set without complaint. Fileside now follows its example.

Less log spew

Fixed a bug where every assert attempt would get printed to the log file even though the assert validated just fine. In fact, asserts have now been completely eliminated from production builds, as they should have been from the beginning.