[sciurius]

During the beta test phase, synchronizing devices created a logfile with the actions that were taken.
This is removed from the production version.

Personally. I would like a log report so I have detailed information on what happened.
Moreover, I would also appreciate these reports for sync to folder and sync to backup.

I do not think it is necessary to retain all info, as it was in the beta. Creating a new log for a synch action is sufficient. Maybe rename a current log to .bak or something similar.
Also, I would appreciate ISO 8601 timestamps in the log .

[Zubersoft]

The problem is that none of the log messages were translated into any other languages (at least the messages that weren't already being written to the status text field).  That is why I removed them. If all you would like is something that writes to disk just what is in that status text field, I can certainly do that. If you were looking for more in-depth information, I don't want to produce a file like that automatically if it isn't translated and is basically worthless to many users (unless the file is generated in a non-obvious location and I overwrite the file each time so that I don't generate an ever growing list of files in the background that users aren't aware of). If you would like a hidden advanced option just for English users that enables logging, I can also look into that.

Mike

[sciurius]

I was already happy with the log file as written in the beta version (except for the date format). The log file was there for people who know how to find it (and how to fetch it). Most users will never look at it. And since the information is very limited (Comparing, Copying, Uploading, ...) I wouldn't worry much about translating it.

But don't spend much time on this, it's a personal wish and there are more important issues to handle.

[itsme]

I fully agree with Sciurius: a log file could be helpful, it is not the most important feature, translating it is not required.

[Geoff Bacon]

The log might also be useful to you in determining what has gone wrong on a user's tablet.

However, simply renaming a previous log to .bak might not be much use as any problems in the initial log will be lost if the user has multiple attempts to get it to work.
Perhaps use the log file date creation time and, instead of simply renaming an existing log to .bak, delete any log files that are older than 5 days (say). This will retain any relevant info but still allow it to be automatically cleaned up at some point.

Geoff