This is the multi-page printable view of this section. Click here to print.
Blog
Version 2.6.3
Version 2.6.3 (build 157) - August 4, 2025
Here are the code updates for the upcoming release, scheduled to be released before the end of August 2025:
Dev build #1 - August 4
- the RsyncUI application icon has been updated using the new Icon Composer tool
- this update supports icons in the new macOS Tahoe 26 and incorporates layered icons, the icon has also undergone a slight redesign, featuring a new cloud and numbers as layers in Icon Composer
- the progress bar displayed during file synchronization has been set to have a fixed width, limiting the maximum number of transferred files
- the Home catalogs view in the Tasks application has undergone a refactor
- select the Home catalogs on the Toolbar in Tasks
- A third method for observers, based on AsyncSequence, has been applied, please refer to blog post Observers for more details
- this method is recommended for observing notifications, a crucial component of RsyncUI
- the third method was inspired by a blog post by Majid Jabrayilov, a frequent blogger about Swift and SwiftUI
The updated icon:
The total number, like 9 068 below, is fixed on line:
Assist in adding new catalogs, refactored to use pickers:
Version 2.6.2
Version 2.6.2 (build 156) - July 21, 2025
Version 2.6.2 of RsyncUI require Xcode 26 and Swift 6.2 to compile.
Updates in this release
There was a request to display the % of completed transfer pr file. It seems difficult to pick up the correct info if like --info=progress2 is added as parameter to rsync. This parameter causes rsync to publish a lot of data, but it is difficult to get the correct info. You may test the parameter yourself by pasting the complete rsync command into a terminal window. But, instead a counter completed files was easy to add.
- only UI updates, no model changes
- added counter files completed and total number of files
- the total number of files requiere an estimation run ahead of synchronization
- the counter is displayed as part of the progress bar
- consistent use of source and destination
ChatGPT says the following: In rsync documentation and usage, the most common terms are source and destination. These clearly indicate where the data is coming from and where it is going. While local and remote can be used when specifying locations across different systems, source and destination are universally applicable for both local and remote transfers.
In version, version 2.6.2, the terms have been revised to consecvent source and destination. The term remote is now exclusively used to refer to remote user and remote server.
Version 2.6.1
Version 2.6.1 (build 155) - July 10, 2025
Version 2.6.1 of RsyncUI require Xcode 26 and Swift 6.2 to compile.
Updates in this release
- fixed issue with text colors if Colorscheme is Light, Colorscheme is Light, Dark or Auto (Apperance in macOS Settings)
- the issue applies only if using Light Colorscheme
- I was not aware of the issues, on both my Macs I was using Dark Colorscheme, now I am using Light Colorscheme on one of my Macs
- the Calendar is renamed to Schedule, and there was an issue loading schedules for “Default” profile
- The Schedule is by default hidden, you may enable it in user settings
- after an estimate run, the Estimate column within main Synchronize view is removed, the Synchronize ID is tagged with color instead and during estimation prefixed by an arrow
- profile picker is hidden if only Default profile in use
- if a new profile is added, the profile picker is present
- also applies to profile picker if Sidebar menu is hidden
- in Tasks view, buttons for saving URL strings are refactored
- the URL strings are added to Rsync Parameters view
- refactor of the Verify Remote function, caution this is a special function and please read about it within the Documentation, refer to the Verify remote section.
- the output, estimates, from both pull and push are now by default not adjusted
- there are added three colors for rows tagged for: delete, pull and push, it might assist in deciding push or pull
- from the result of push and pull, go direct to either push or pull view
- refactor of write and read to logfile as actor, writing and reading to logfile is now on a background thread
- the Import function is refactored
- see File->Export & Import->Import
- added new concurrency keywords
- new keywords included Swift version 6.2
And there is a detailed changelog from the release page GitHub. There are not any updates or refactors to the main parts of RsyncUI, like estimation, execution, process apart from some new concurrency keywords (Swift 6.2) added to the actors.
New concurrency keywords and AI generated commit comments
There is a new beta of Xcode and Swift 6, Xcode 26 and Swift 6.2. There are some new features regarding concurrency in Swift 6.2 and I have just started to read and learn more about them. The GitHub Desktop now includes generating commit comments by GitHub Copilot. From version 2.6.0 of RsyncUI there is more info about the commits.
Macos 26 Tahoe
I have tested installing, by Homebrew, the latest version of RsyncUI on a virtual macOS 26 Tahoe. I did also install the latest version of rsync by Homebrew. And by a short test only, both RsyncUI and the latest version of rsync did run as expected.
And I have commenced some testing and development on the virtual macOS 26 Tahoe and Xcode 26 beta. It might be some macOS 26 Tahoe specific changes to RsyncUI, but it will still support for the last three versions of macOS. Any macOS 26 Tahoe specific changes are handled by compiler directives in code.
Version 2.5.9
Version 2.5.9 (build 153) - June 16, 2025
This is as previous release, mostly a maintenance release. I have also, for test, compiled RsyncUI with the Xcode 26 beta. And it compiled with no errors as expected. There will be a new release when macOS Tahoa 26 and Xcode 26 with Swift version 6.2 is avaliable as release candidates. I dont know when this happens, but most likely in Sept or October sometime. And of course, if bugs are found a fix will be relased.
The following are changes in this release:
- a few internal refactors
- three objects for estimation and execution are merged into one object, cleaner code and easier to read
- two objects for monitoring state estimate and execute are removed, the Process object which executes the external rsync task is reporting when the external task is sending a ProcessTermination signal
- by the above we know when a process starts, when it is in progress and when it is completed, dont need any state object for monitoring progress
- removed not used properties like the profile name
- the profile picker uses the UUID (the id) to compute the profile name when a new profile is selected
- makes the code easier to read, less prone for errors when code is changed and less properties for RsyncUI to monitor
- added a couple of more checks before executing tasks
- one check is if more than one task is selected, the double click function is disabled
- a few UI updates as well
Less code is better code.
Version 2.5.8
Version 2.5.8 (build 152) - June 5, 2025
This is a maintenance release. The release is signed and notarized by Apple. There are quite a few minor updates:
- refactor, internal, merge of two objects for monitoring progress of estimation and the real synchronization task
- there was an issue with progress view during synchronization of a task by using “double click”
- the first double click executes an estimate run, a -dry-run
- the next double click executes the real synchronization of data
- the bug caused the progress view is a spinning circular image and not the real progress
- if only one task, either selected or in configuration, when pressing Magic Wand for estimating task within main Synchronize view, default progress view is presented and not number of tasks estimate is completed
- the default progress view is a spinning circular image
- if more than one task, the progress view presents the number of tasks estimate is completed
- in Profile view, now correct updating the profile picker when adding or delete profiles
- the correct profile is actually loaded, but profile picker is not correctly set
- removed profile name from most tables, display profile name in heading view
- makes more room for display other info in tables
- internal refactor, every time a “/”, forward slash, is added, using the library function
.appending(_other: some StringProtocol)- before used the
+sign, likestring + "/", after refactorstring.appending("/")
- before used the
- fixed updating profile picker when RsyncUI discover new mounts and automatically loads profile
- within the released version the profile picker does not show the correct profile loaded
- the correct profile is actually loaded
- removed the weekly option from Calendar, only once and daily are schedule options
- within the Verify remote view, changed the toggle for delete parameter in pull and push
- when choosing either pull or push, the delete parameter is included as default
The blog “Number of files” presents the number of files in RsyncUI. Within this release there are 228 Swift files and 17,900 lines of code.
Version 2.5.5
Version 2.5.5 (build 147) - May 23, 2025
This is a maintenance release. In the latest release, there were several UI updates. This release fixes some of the minor issues discovered after previous release. There is also one refactor of internal code, see comment about Picker and optional values.
- a few days ago I did read a blog about Picker and nil values and how to deal with optional values
- a Picker is like the profile selector and optional values means there may be no selected value (
nil) - when a new user commence using RsyncUI, there are no profiles but only the default path, the profile picker has no values but
nil - a profile is a folder and RsyncUI stores data for profile in folder (or directory), the profile name, displayed in profile picker, is name of the folder
- a Picker is like the profile selector and optional values means there may be no selected value (
- if you have ON “Observe mounting of external drives” in settings, RsyncUI will automatically load profile if mounted volume path in destination
- when unmounting the volume, RsyncUI now also automatically load default profile
- the automated selection of profile when mounting a volume is only valid if there is created one or more profiles
- in Tasks, view for adding new tasks, pressing the Enter key does not jump to the next logical field in view
- pressing Enter key automatically jumps to next input field and by end automatically adds new task
- in QuickTasks, RsyncUI flips source and destination when executing a syncremote task, aka pull data from destination to source
- Quicktask is also only valid if there is a remote server involved, for local attached volumes use the macOS Finder
- there is a minor issue selecting a task for adding parameters to rsync within the Rsync parameters view
- the issue occurs if there is selected a task in the main Synchronize view, switch to Rsync parameters view, selecting the task will not enable adding parameters to rsync
- the issue is caused due to the fix for situation where RsyncUI become unresponsive with a bouncing beach ball, see comments for blog about version 2.5.3
- the global replace function, in Tasks view, select the Globus on the toolbar
- left text field part of text to be replaced
- right text field replaced with what
- any part of word may be replaced, as soon as you start type in the replace field the view is dynamically updated
Version 2.5.3
Version 2.5.3 (build 145) - May 14, 2025
Major updates in the this release are, a detailed changelog on the GitHub release page. And thanks very much to Johnny Sauce for valuable input and feedback.
- a fix for the above mentioned spinning beach ball
- the Verify Remote is now not enabled by default, enable in User settings
- the Verify Remote function is slightly changed as well
- please read about the function in section Verify Remote
- update changes in User settings is now manual update, the automated save settings when changed did not work 100%
- there is a new view for Verify Tasks
- the verify buttons, play icon, in Tasks and Rsync parameters are removed
- the new view is very explicit about dry-run parameter is enabled
- German and Norwegian localization are deleted
- regrettably, due to my limited proficiency in German, I am unable to provide a comprehensive translation in German. From this version, RsyncUI speaks English only
- the Tasks view is cleaned up, new help button for info add and delete the –delete parameter to rsync
- add or delete, by default not added when new tasks
- the Rsync parameters view is cleaned up, new help button for info add and delete the –delete parameter to rsync
- the annoying popup when adding SSH-keys in Tasks and SSH-settings are removed and replaced
- the values added are marked red text until values are compliant with validated input
- example, if you add like
22din SSH port number, the text is marked red until the letterdis removed
- the annoying popup adding your own path for rsync and restore path is also removed and replaced with red text until validated OK
- a new calendar for schedule actions, please read about the scheduler below before commence using it
- to delete a schedule, just select it and press the back space button
Number of files
Numbers updated: June 16, 2025, version 2.5.9
There is a very nice and excellent tool, cloc (https://github.com/AlDanial/cloc), for counting of files and lines of code. Below are the numbers for Swift files which are part of the repository for compiling RsyncUI. RsyncUI does not rely on external libraries; it is constructed using default Swift libraries and Swift/SwiftUI code exclusively.
The number of files and lines of code are reduced from version 2.5.8 to version 2.5.9.
- from 228 files to 221
- from 17,992 lines of code to 17,835 lines
cloc DecodeEncodeGeneric ParseRsyncOutput RsyncArguments RsyncUI RsyncUIDeepLinks SSHCreateKey
306 text files.
273 unique files.
71 files ignored.
github.com/AlDanial/cloc v 2.04 T=0.13 s (2116.6 files/s, 357686.2 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Text 6 12 0 21921
Swift 221 2369 2679 17835
XML 25 0 0 593
C 2 36 72 254
JSON 8 0 0 180
make 1 22 2 59
Markdown 6 33 0 48
YAML 2 0 0 12
Bourne Shell 1 0 1 2
C/C++ Header 1 1 3 0
-------------------------------------------------------------------------------
SUM: 273 2473 2757 40904
-------------------------------------------------------------------------------
Main Repository:
- RsyncUI (https://github.com/rsyncOSX/RsyncUI) - The primary repository for RsyncUI.
Local RsyncUI packages:
SPM, Swift Package Manager, makes it easy to create local packages. And each package containes their own tests by Swift Testing, the new framwork for creating tests. All packages are created by me.
- RsyncArguments (https://github.com/rsyncOSX/RsyncArguments) - Generate parameters for
rsyncbased on configurations. - sshCreateKey (https://github.com/rsyncOSX/sshCreateKey) - Assist in creating an SSH identity file and key using RsyncUI.
- Generate an RSA-based SSH key for default and user-defined keys, including the SSH port number.
- DecodeEncodeGeneric (https://github.com/rsyncOSX/DecodeEncodeGeneric) - Generic code for decoding and encoding JSON data.
- ParseRsyncOutput (https://github.com/rsyncOSX/ParseRsyncOutput) - Parse and extract numerical values from the output of
rsync. This data is used to display details and log results for synchronized tasks. - RsyncUIDeepLinks (https://github.com/rsyncOSX/RsyncUIDeepLinks) - parse end return valid URL deeplink for execute tasks direct within RsyncUI
Historic releases
Previous releases
Version and dates only:
- Version 2.4.1 - 2025-03-21
- Version 2.3.9 - 2025-03-09
- Version 2.3.7 - 2025-03-07
- Version 2.3.5 - 2025-02-26
- Version 2.3.4 - 2025-02-12
- Version 2.3.2 - 2025-01-29
- Version 2.3.0 - 2025-01-15
- Version 2.2.5 - 2025-01-08
- Version 2.2.3 - 2024-12-20
- Version 2.2.1 - 2024-11-30
- Version 2.2.0 - 2024-11-29
- Version 2.1.8 - 2024-11-14
- Version 2.1.6 - 2024-10-29
- Version 2.1.5 - 2024-10-13
- Version 2.1.4 - 2024-09-27
- Version 2.1.3 - 2024-09-16
- Version 2.1.1 - 2024-07-30
- Version 1.9.2 (build 100) - 11 June 2024
- Version 1.9.1 (build 99) - 27 May 2024
- Version 1.9.0 (build 98) - 12 April 2024
- Version 1.8.9 (build 97) - 26 March 2024
- Version 1.8.8 (build 96) - 14 March 2024
- Version 1.8.7 (build 95) - 20 February 2024
- Version 1.8.6 (build 94) - 30 January 2024
- Version 1.8.2 (build 92) - 8 January 2024
- Version 1.8.1 (build 91) - 29 December 2023
- Version 1.8.0 (build 90) - 18 December 2023
- Version 1.7.9 (build 89) - 7 December 2023
- Version 1.7.8 build (88) and 1.7.5 build (88) - 23 November 2023
- Version 1.7.3 build (86) - 19 October 2023
- Version 1.7.5 build (84) - 28 September 2023
- Version 1.7.2 build (85) - 23 September 2023
- Version 1.7.1 build(83) - 1 September 2023
- Version 1.7.0 build(82) - 16 August 2023
- Version 1.6.6 build(81) - 1 August 2023
- Version 1.6.5 build(80) - 16 July 2023
- Version 1.6.3 build(79) - 29 June 2023
- Version 1.6.1 build(77) - 20 June 2023
- Version 1.6.0 build(76) - 16 June 2023
- Version 1.5.0 build(73) - 4 May 2023
- Version 1.4.8 build(70) - 24 March 2023
- Version 1.4.7 build(69) - 14 March 2023
- Version 1.4.5 build(67) - 7 March 2023
- Version 1.4.3 build (65) - 8 February 2023
- Version 1.4.2 build (64) - 6 January 2023
- Version 1.4.0 build (62) - 6 December 2022
- Version 1.3.9 build (57) - 18 November 2022
- Version 1.3.8 build (56) release candidate - 10 November 2022
- Version 1.3.7 build (56) - 5 November 2022
- Version 1.3.6 build (55) - 31 October 2022
- Version 1.3.0 build (53) - 30 September 2022
- Version 1.2.9 build (52) - 8 September 2022
- Version 1.2.8 build (51) - 20 March 2022
- Version 1.2.7 build (50) - 17 March 2022
- Version 1.2.6 build (48) - 31 December 2021
- Version 1.2.5 build (48) - 6 December 2021
- Version 1.2.3 build (46) - 11 November 2021
- Version 1.2.2 build (45) - 28 October 2021
- Version 1.2.1 build (42) - 21 October 2021
- Version 1.2.0 build (41) - 28 September 2021
- Version 1.1.2 build (40) - 9 September 2021
- Version 1.1.2 build (39) - 1 September 2021
- Version 1.1.2 build (38) - 28 August 2021
- Version 1.1.2 build (37) - 21 August 2021
- Version 1.1.2 build (36) - 16 August 2021
- Version 1.1.2 build (35) - 11 August 2021
- Version 1.1.2 build (34) - 30 July 2021
- Version 1.1.2 build (28)
- Version 1.1.1 build (27)
- Version 1.1.0 build (26)
- Version 1.0.1 build (24)
- Version 1.0.0 build (23)
- Prerelease version 0.99 build (22)
- Prerelease v0.60 build (20) - breaking changes
- Prerelease v0.55 build (19) - 14 April 2021
- Prerelease v0.49 build (18)
- Prerelease v0.48 build (17)
- Prerelease v0.47 build (16)
- Prerelease v0.45 build (15)
- Prerelease v0.42 build (14)
- Prerelease v0.41 build (12)
- Prerelease v0.39 build (11)
- Prerelease v0.36 build (10)
- Prerelease v0.36 build (8)
- Prerelease v0.35 build (7)
- Prerelease v0.3 build (6) - 12 March 2021
Observers
A key feature of RsyncUI is observation for two notifications:
NSNotification.Name.NSFileHandleDataAvailableProcess.didTerminateNotification
Without observation and required actions when observed, RsyncUI becomes useless. Both observations are linked to the external task executing the actual rsync task.
Notifications
The initial notification, NSNotification.Name.NSFileHandleDataAvailable, monitors the generation of output by the external task. To display the progress of a synchronization task, RsyncUI relies on monitoring the output from rsync. Consequently, the —verbose parameter to rsync is essential. This parameter instructs rsync to output information during execution.
The second notification, Process.didTerminateNotification, monitors the termination of the task, such as an abrupt halt. Typically, a termination signifies task completion. However, it can also indicate an abort action from the user, which subsequently sends an interrupt signal to the external task. If RsyncUI fails to detect this signal, it will be unable to discern when a synchronization task has been completed.
New method for observing notifications
In the latest version of RsyncUI (2.6.3), a new method for observing notifications have been introduced. After some investigation and recommendation, the AsyncSequence method emerges as the preferred approach. By applying this the Combine Framework and depended code is removed.
NotificationCenter.Notifications and AsyncSequence - new and applied method
The await/async API appears to be the recommended method. As stated in Apple documentation, “An asynchronous sequence of notifications generated by a notification center.” The for await loops iterate over the notifications and respond to each one. When the termination signal is detected, the tasks must also be canceled, and the observers must be removed.
// AsyncSequence
let sequencefilehandler = NotificationCenter.default.notifications(named: NSNotification.Name.NSFileHandleDataAvailable, object: nil)
let sequencetermination = NotificationCenter.default.notifications(named: Process.didTerminateNotification, object: nil)
// Tasks
var sequenceFileHandlerTask: Task<Void, Never>?
var sequenceTerminationTask: Task<Void, Never>?
....
sequenceFileHandlerTask = Task {
for await _ in sequencefilehandler {
await self.datahandle(pipe)
}
}
sequenceTerminationTask = Task {
for await _ in sequencetermination {
Task {
try await Task.sleep(seconds: 0.5)
await self.termination()
}
}
}
Upon task completion, the Observers must be released, and corresponding Tasks must be canceled to prevent a retain cycle and memory leak.
func datahandle(_ pipe: Pipe) async {
let outHandle = pipe.fileHandleForReading
let data = outHandle.availableData
if data.count > 0 {
if let str = NSString(data: data, encoding: String.Encoding.utf8.rawValue) {
str.enumerateLines { line, _ in
self.output.append(line)
if SharedReference.shared.checkforerrorinrsyncoutput,
self.errordiscovered == false
{
do {
try self.checklineforerror?.checkforrsyncerror(line)
} catch let e {
self.errordiscovered = true
let error = e
self.propogateerror(error: error)
}
}
}
// Send message about files
if usefilehandler {
filehandler(output.count)
}
}
outHandle.waitForDataInBackgroundAndNotify()
}
}
func termination() async {
processtermination(output, config?.hiddenID)
// Log error in rsync output to file
if errordiscovered, let config {
Task {
await ActorLogToFile(command: config.backupID,
stringoutputfromrsync: output)
}
}
SharedReference.shared.process = nil
// Remove observers
NotificationCenter.default.removeObserver(sequencefilehandler as Any,
name: NSNotification.Name.NSFileHandleDataAvailable,
object: nil)
NotificationCenter.default.removeObserver(sequencetermination as Any,
name: Process.didTerminateNotification,
object: nil)
// Cancel Tasks
sequenceFileHandlerTask?.cancel()
sequenceTerminationTask?.cancel()
Logger.process.info("ProcessRsyncAsyncSequence: process = nil and termination discovered")
}
Combine and Publisher - REMOVED
The Combine framework is utilized within the ProcessRsync and ProcessCommand objects, which is responsible for initiating external tasks, such as the rsync synchronize task. The rsync synchronize task is completed when the last notification is observed. By using Combine, a publisher is added to the Notification center. Every time the Notification center discover one of the notifications, it publish a message.
// Combine, subscribe to NSNotification.Name.NSFileHandleDataAvailable
NotificationCenter.default.publisher(
for: NSNotification.Name.NSFileHandleDataAvailable)
.sink { [self] _ in
....
}.store(in: &subscriptons)
// Combine, subscribe to Process.didTerminateNotification
NotificationCenter.default.publisher(
for: Process.didTerminateNotification)
.debounce(for: .milliseconds(500), scheduler: DispatchQueue.main)
.sink { [self] _ in
....
subscriptons.removeAll()
}.store(in: &subscriptons)
NotificationCenter and addObserver - REMOVED
The second method for observing notifications involves adding Observers to the Notification center. Upon the discovery of a notification, the completion handler is executed. The Process object is annotated to execute on the main thread. It appears that the addObserver closure is marked as Sendable, indicating that mutating properties within the closure must be asynchronous. This is due to the Swift 6 language mode and strict concurrency checking.
// Observers
var notificationsfilehandle: NSObjectProtocol?
var notificationstermination: NSObjectProtocol?
....
notificationsfilehandle =
NotificationCenter.default.addObserver(forName: NSNotification.Name.NSFileHandleDataAvailable,
object: nil, queue: nil)
{ _ in
Task {
await self.datahandle(pipe)
}
}
notificationstermination =
NotificationCenter.default.addObserver(forName: Process.didTerminateNotification,
object: task, queue: nil)
{ _ in
Task {
// Debounce termination for 500 ms
try await Task.sleep(seconds: 0.5)
await self.termination()
}
}
Upon task completion, the Observers must be released to prevent a retain cycle and memory leak.
func datahandle(_ pipe: Pipe) async {
let outHandle = pipe.fileHandleForReading
let data = outHandle.availableData
if data.count > 0 {
if let str = NSString(data: data, encoding: String.Encoding.utf8.rawValue) {
str.enumerateLines { line, _ in
self.output.append(line)
if SharedReference.shared.checkforerrorinrsyncoutput,
self.errordiscovered == false
{
do {
try self.checklineforerror?.checkforrsyncerror(line)
} catch let e {
self.errordiscovered = true
let error = e
self.propogateerror(error: error)
}
}
}
// Send message about files
if usefilehandler {
filehandler(output.count)
}
}
outHandle.waitForDataInBackgroundAndNotify()
}
}
func termination() async {
processtermination(output, config?.hiddenID)
// Log error in rsync output to file
if errordiscovered, let config {
Task {
await ActorLogToFile(command: config.backupID,
stringoutputfromrsync: output)
}
}
SharedReference.shared.process = nil
NotificationCenter.default.removeObserver(notificationsfilehandle as Any,
name: NSNotification.Name.NSFileHandleDataAvailable,
object: nil)
NotificationCenter.default.removeObserver(notificationstermination as Any,
name: Process.didTerminateNotification,
object: nil)
Logger.process.info("ProcessRsyncObserving: process = nil and termination discovered")
}
Swift concurrency
To begin, I must admit that my knowledge of Swift concurrency is limited. I have a basic understanding of the subject, and if you are reading this blog and seeking further details about the topic, I recommend conducting a search and reading articles from other sources that provide a more comprehensive understanding of Swift concurrency.
RsyncUI is a graphical user interface (GUI) application; the majority of its operations are executed on the main thread. However, some resource-intensive tasks are performed on other threads managed the cooperative thread pool (CTP), excluding and not blocking the main thread. How to the executors and CTP works and interacts is details I dont know about, and it is managed by the Swift runtime. There are three kinds of executors:
- the main executor manage jobs on the Main Thread
- the global concurrent executor and the serial executor, both executes jobs on threads from the CTP
The most important work are executed on the Main Thread. By default, SwiftUI makes sure all UI-updates are performed on the Main Thread. Below are other tasks on the Main Thread:
- preparing of and execution of
rsyncsynchronize tasks, preparing is computing the correct arguments for rsync - monitoring progress and termination of the real rsync tasks
- write operations of logdata of synchronize tasks to storage
- write and read the logfile for RsyncUI
All read and write operations, transmission of the synchronized data is outside control of RsyncUI and taken care of by rsync itself.
Swift concurrency and asynchronous execution
Concurrency and asynchronous execution are important parts in Swift. The latest version of Swift simplifies the writing of asynchronous code using Swift async and await keywords, as well as the actor protocol. RsyncUI does not require concurrency, but concurrency is automatically introduced by using actors , async and await keywords. It is an objective to execute most work synchronous on the main thread as long as it does not block the GUI.
Swift version 6 and the new concurrency model
Swift version 6 introduced strict concurrency checking. By enabling Swift 6 language mode and strict concurrency checking, Xcode assists in identifying and resolving possible data races at compile time.
Quote swift.org: “More formally, a data race occurs when one thread accesses memory while the same memory is being modified by another thread. The Swift 6 language mode eliminates these issues by preventing data races at compile time.”
RsyncUI adheres to the new concurrency model of Swift 6.
Cooperative thread pool (CTP)
The following tasks are executed asynchronous on threads from the CTP, adhering to the actor protocol:
- all reading operations
- data decoding and encoding
- sorting log records
- preparing output from rsync for display
- preparing data from the logfile, not logrecords, for display
- checking for updates to RsyncUI
- write data to RsyncUI logfile
Adhering to the actor protocol, all access to properties within an actor must be performed asynchronously. There are three types of executors, which manages jobs and put jobs on threads for execution.
The above mentioned tasks are executed on threads from the CTP, and not on the@MainActor. The Swift concurrency runtime handles scheduling and execution, guaranteeing that all functions within an actor are nonisolated func, which to my understanding, guarantees asynchronous execution on threads from the CTP.
Structured concurrency
Some concurrent functions within RsyncUI are structured by using async let. You may have several async let, and they will all be executed in parallel or concurrent. When all async let tasks are completed, the root task or parent task, will continue execution.
func readconfigurations() {
Task {
async let readconfigurations = ActorReadSynchronizeConfigurationJSON()
let data = await readconfigurations
.readjsonfilesynchronizeconfigurations(selectedprofile,
SharedReference.shared.monitornetworkconnection,
SharedReference.shared.sshport)
// after the await is completed, the root task will continue
// the structured concurrency is actually not needed here, only one async let
rsyncUIdata.configurations = data
}
}
The below code is unstructured concurrency. The root function readconfigurations() may be completed before the asynchronous code within the Task {}.
func readconfigurations() {
Task {
rsyncUIdata.configurations = await ActorReadSynchronizeConfigurationJSON()
.readjsonfilesynchronizeconfigurations(selectedprofile,
SharedReference.shared.monitornetworkconnection,
SharedReference.shared.sshport)
}
}
Unstructured concurrency
The code snippet below presents an unstructured concurrency. The code within the Task { ... } may be completed after the execution of the calling function, the parent, is completed. Upon the function’s return, the UI is notified on the main thread if there is a new version available.
@MainActor
func somefunction() {
Task {
newversion.notifynewversion = await GetversionofRsyncUI().getversionsofrsyncui()
}
}
Access to properties within an actor must be performed asynchronously, that is why the Task { ... } above is requiered. The Swift runtime makes sure that only one thread a time get access to properties within an actor. The code below is probably not an OK example. The main reason for make this an actor is to execute it on a thread from the CTP for not block the Main Thread.
actor GetversionofRsyncUI {
nonisolated func getversionsofrsyncui() async -> Bool {
do {
let versions = await DecodeGeneric()
if let versionsofrsyncui =
try await versions.decodearraydata(VersionsofRsyncUI.self,
fromwhere: Resources().getResource(resource: .urlJSON))
{
let runningversion = Bundle.main.infoDictionary?["CFBundleShortVersionString"] as? String ?? ""
let check = versionsofrsyncui.filter { runningversion.isEmpty ? true : $0.version == runningversion }
if check.count > 0 {
return true
} else {
return false
}
}
} catch {
return false
}
return false
}
}
Example of bug in RsyncUI concurrency
There was a bug within RsyncUI prior to version 2.5.8. The bug caused only a circular rotating wheel for the progress when executing the real synchronization task when using double click on task. The synchronization of data was executed, but there was no progress bar. The bug was caused because of the allocation if let remotedatanumbers { ... } was after the Task { ... } and not within as shown below. The calling function was completed before the Task { ... } and the actual output from rsync was not allocated to the remotedatanumbers object. And when the user executes the second double click, the real output from rsync was not set.
func processtermination(stringoutputfromrsync: [String]?, hiddenID: Int?) {
...
Task {
remotedatanumbers?.outputfromrsync = await CreateOutputforviewOutputRsync()
.createoutputforviewoutputrsync(stringoutputfromrsync)
if let remotedatanumbers {
progressdetails.appendrecordestimatedlist(remotedatanumbers)
}
estimateiscompleted = true
}
...
}
Tagging of data
Tagging of data to be synchronized
It is imperative that RsyncUI tags tasks with data to be synchronized correctly. If the tagging fails, there may be source data that is not synchronized. RsyncUI supports the latest version of rsync and the older default version of rsync included in macOS 14 and macOS 15.
The tagging of data to be synchronized is computed within the package ParseRsyncOutput, a local Swift Package for RsyncUI.
From version 2.4.0, there is a verification of the tagging, if the output from rsync is greater than 20 lines and tagging for data to synchronize is not set, an alert is thrown. Normally, if there are no data to synchronize output from rsync is about 20 lines. Extract numbers from a string containing letters and digits is from version 2.4.0 of RsyncUI is now a one line code.
Example:
- the string
Number of created files: 7,191 (reg: 6,846, dir: 345)as input - is converted to
[7191,6846,345], the thousand mark is also removed from string ahead parsing
The function below extract numbers only from the input.
public func returnIntNumber( _ input: String) -> [Int] {
var numbers: [Int] = []
let str = input.replacingOccurrences(of: ",", with: "")
let stringArray = str.components(separatedBy: CharacterSet.decimalDigits.inverted).compactMap { $0.isEmpty == true ? nil : $0 }
for item in stringArray where item.isEmpty == false {
if let number = Int(item) {
numbers.append(number)
}
}
if numbers.count == 0 {
return [0]
} else {
return numbers
}
}
The parsing of the output of rsync is not particularly complex, and it is somewhat different for the latest version of rsync compared to the default versions of rsync.
Latest version of rsync
The trail of output from latest version of rsync, version 3.4.1, is like:
....
Number of files: 7,192 (reg: 6,846, dir: 346)
Number of created files: 7,191 (reg: 6,846, dir: 345)
Number of deleted files: 0
Number of regular files transferred: 6,846
Total file size: 24,788,299 bytes
Total transferred file size: 24,788,299 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.003 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 394,304
Total bytes received: 22,226
sent 394,304 bytes received 22,226 bytes 833,060.00 bytes/sec
total size is 24,788,299 speedup is 59.51 (DRY RUN)
Default version of rsync
The trail of output from default version of rsync is like:
....
Number of files: 7192
Number of files transferred: 6846
Total file size: 24788299 bytes
Total transferred file size: 24788299 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 336861
File list generation time: 0.052 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 380178
Total bytes received: 43172
sent 380178 bytes received 43172 bytes 169340.00 bytes/sec
total size is 24788299 speedup is 58.55
How does the tagging work
The output from rsync is parsed and numbers are extracted. After parsing of output, the numbers decide if there is tagging of data to be synchronized.
Latest version of rsync
There are three numbers which decide data to synchronize or not: number of updates (regular files transferred), new files or deleted files. And they all may be 0 or a number, all three must be verified.
Default versions
There is only one number which decide data to synchronize or not: number of updates (files transferred).
Timer and Schedule
The Timer and Schedule
The Schedules is developed by utilizing the Timer library. The actual synchronize task is kicked off when the scheduler writes the profile name to an observed value monitored by RsyncUI. The profile name is added to the schedule itself, the callback does the update of the observed value when the timer is kicked off.
When RsyncUI observes that the value is updated, it trigger a URL-function in RsyncUI by using the profile name, the URL-function then kick off the actual synchronization task.
If RsyncUI is alive, any update of the observed value will commence a synchronization task. The weak spot is how the Timer works and its limitations.
The Timer code
The Timer is a Global static class with one task only, keep track of one timer which is the first timer to kick off. It also executes the callback function when the timer is kicked off. There are one other major part of the Calendar function, the object which calculates next time and display futures timers when there is an update.
The Calenderview asks the calendear object when the user views this and futures months. The Calendar view is dynamically updated, based on the input within the calendar table view.
The Global static timer only keeps track of one timer.
To wrap it up, the Timer itself is very easy but with limitations. The calendar object is somewhat more complex, with two major tasks:
- compute the next timer to execute and update the Global static timer
- provide the Calenderview with future times, computed only when the user browse the calendar
//
// GlobalTimer.swift
// Calendar
//
// Created by Thomas Evensen on 31/03/2025.
//
import Foundation
import Observation
import OSLog
@Observable
final class GlobalTimer {
@MainActor static let shared = GlobalTimer()
private init() {}
var timer: Timer?
// Only used for message in SidebarMainView
@ObservationIgnored var schedule: String?
private var schedules: [String: (time: Date, callback: () -> Void)] = [:]
func addSchedule(profile: String?, time: Date, callback: @escaping () -> Void) {
if profile == nil {
Logger.process.info("GlobalTimer: addSchedule() - profile Default at time \(time)")
schedules["Default"] = (time, callback)
} else if let profile {
Logger.process.info("GlobalTimer: addSchedule() - profile \(profile) at time \(time)")
schedules[profile] = (time, callback)
}
start()
}
func clearSchedules() {
guard schedules.count > 0 else {
Logger.process.info("GlobalTimer: clearSchedules() NO timer to invalidate")
timer?.invalidate()
timer = nil
return
}
Logger.process.info("GlobalTimer: clearSchedules() and INVALIDATE old timer")
schedules.removeAll()
timer?.invalidate()
timer = nil
}
private func start() {
if timer == nil {
Logger.process.info("GlobalTimer: start() new timer")
timer = Timer.scheduledTimer(timeInterval: 60.0,
target: self,
selector: #selector(checkSchedules),
userInfo: nil,
repeats: true)
}
}
@objc private func checkSchedules() {
for (name, schedule) in schedules {
Logger.process.info("GlobalTimer: checkSchedules(): Date.now \(Date.now) and schedule.time \(schedule.time)")
if Date.now >= schedule.time {
Logger.process.info("GlobalTimer: checkSchedules() - timer \(name) fired")
schedule.callback()
}
}
}
}
Tweaking data
RsyncUI is a tool for synchronizing data between a source and a destination. While it is a standard tool, utilizing it for specialized tasks that require specific parameters can sometimes be challenging. However, you can manually adjust the data to enable its use.
RsyncUI does not validate the parameters added to the rsync command. If there are parameters that rsync does not comprehend, the task verification will result in an error. Therefore, you can freely specify the parameters you need for rsync. You can also begin with initial values and modify them in the exported JSON file. Subsequently, import the file to verify its functionality.
The “Export & Import” option is selected from the menu bar when in the main Synchronize view form. If the modified JSON becomes malformed, the import will only generate an error.
Important: The blue keywords in the provided JSON sample are internal to RsyncUI and may not always align with the views displayed. For instance, the keyword “offsiteCatalog” serves as the internal storage for “destination.” The variation in internal keywords is solely due to the history, preventing users from modifying or adding tasks when new versions of RsyncUI are released.
[{"offsiteCatalog":"Destination Folder\/","parameter2":"--verbose","backupID":"Synchronize ID test","parameter3":"--compress","dateRun":"","parameter8":"--userparam1=value","parameter9":"--userparam2=value","parameter12":"--userparam5=value","parameter1":"--archive","task":"synchronize","offsiteUsername":"Remote User","halted":0,"parameter11":"--userparam4=value","id":"E62C46B3-5C57-4C22-864E-359F96D13C2E","parameter13":"--userparam6=value","parameter14":"--userparam7= value","hiddenID":1,"parameter10":"--userparam3=value","localCatalog":"Source Folder\/","offsiteServer":"Remote Server","parameter4":"--delete"}]
URLs Notepad
A few samples of URL´s I am executing from Notepad. URL´s must start with rsyncuiapp://, if not RsyncUI will not recognize the command. My URL´s saved in Notepad for easy access and execution of my most used tasks. The Notepad page might also be saved as a PDF document which includes til URL links.
Sample URLs which I am using
URLs for estimate and execute.
Remote server - raspberrypi with zfs filesystem
rsyncuiapp://loadprofileandestimate?profile=Picturesrsyncuiapp://loadprofileandestimate?profile=default
NVME SSD disks
The mount point, such as /Volumes/WDBackup, and the profile name are set to the same value solely for the purpose of simplifying the identification of the mounted disk and the corresponding profile to use in RsyncUI. As documented here, I am performing backups on several SSD disks and also to a remote server. The rationale behind having multiple backups is that it is straightforward to update all backups on a regular basis using RsyncUI. Additionally, if one disk or the server fails, I always have an updated backup to restore from.
Mounted as WDBackup
rsyncuiapp://loadprofileandestimate?profile=WDBackup
Mounted as Samsung
rsyncuiapp://loadprofileandestimate?profile=Samsung
Mounted as LaCie
rsyncuiapp://loadprofileandestimate?profile=LaCie
URL for verify a remote
Verify remote is only for remote destinations. Remote server - raspberrypi with zfs filesystem. Profile is Pictures and Synchronize ID = Pictures backup, the space is replaced by a _ in URL for the id tag in URL, which is the search for the wanted Synchronize ID.
rsyncuiapp://loadprofileandverify?profile=Pictures&id=Pictures_backup
Console and OSLog
Included in Swift 5 is a unified logging feature called OSLog. This feature provides several methods for logging and investigating the application’s activities. By utilizing OSLog, print statements are no longer necessary to follow the execution of code. All logging is performed through OSLog, which is displayed as part of Xcode. OSLog is integrated into all objects that perform work, making it straightforward to identify which commands RsyncUI is executing.
OSLog information in Xcode. The logging displays commands and arguments as shown below. This feature facilitates the verification that RsyncUI is executing the correct command.
And the OSLogs might be read by using the Console app. Be sure to set:
- the Action in Console app menu to
Include Info Messages - enter
no.blogspot.RsyncUIas subsystem within the Search field
