By collecting telemetry in FileSorterX it can help provide us valuable insights into how our users are interacting with FileSorterX. It can help us identify issues and bugs, as well as areas where our users may be struggling or encountering errors. By including details such as the timestamp, UUID, operating system, command, input/output directories, nesting level, and other parameters, We can get a comprehensive understanding of how the app is being used and what potential issues may be arising. This data can be incredibly useful when it comes to debugging and improving the user experience. When users report issues, having access to this telemetry can help us replicate the problem and diagnose the root cause quickly, leading to faster resolution and a better user experience overall for everyone.
Due to the nature of the telemetry in FileSorterX being optional. As of version 1.2.2+ any and all telemetry will be OFF by default. However there is one version with telemetry on by default v1.2.1 if you use this version of our application you will need to disable telemetry manually by parsing -d
or --disable-telemetry
in the beginning of your command. An example of a command without telemetry would be as follows. filesorterx -d sort -i . -o ./sorted -vl
We only store up to 50 of the most recent commands ran with telemetry enabled. This way we can ensure that if the data isn't being used for issues; reports etc. Users can rest easy that their data is being deleted.
Telemetry is only a feature of the base CLI application as of v.1.2.1+ the library has no form of data collection what so ever, outside of how many times the crate has been downloaded in total. This is not a metric we can control as our platform manager crates.io provides that metric by default. With no option to disable it.