No more "features" please until bigger issues are solved

[publicemaildump751]

Hello,
So, this software has a dizzyingly fast update cycle. I don't know how the developer does it. However, lately (after version 10.0), every time I try to upgrade past that point, I see more and more issues. Developer, I think you need to pause pushing out "features" all the time, and fix the big issues. I will update this post as I remember more issues, but ones I can think of immediately are:

Note: all issue are as seen on Linux Mint Cinnamon x64 V19 - 19.1 (Cinnamon version 4.0.9, Kernel 4.15.0-46-generic, Nemo 4.0.6). I observed that in general, the Windows version has much fewer of these issues, but I use Windows only in rare instances.

- After version 10.0, I can no longer launch FreeFileSync from a desktop symlink created by right-clicking on the software, and then moving the symlink to the desktop. But I can launch it by clicking on the binary/executable itself. ??? If this is specific to a bug in Linux, someone please let me know. I have a faint recollection that one or two other software I use also cannot launch from a desktop link. The only workaround is by a custom .desktop file as shown below.

- After version 10.0, some versions will plain never launch even from the binary, or they crash immediately, although 10.9 does launch from the binary. Before, when there were many Linux compiled versions to choose from, I had to guess the proper binary type by trial and error. Now that we have only one Linux compilation type for FFS to choose from, it is less trial, but nonetheless sometimes posted FFS Linux version executable plain does not run.

- After version 10.0, program is very likely to crash while I am using configuration files from an older (tried and tested) 10.0 installation. Only some of my many configuration files fail. But software immediately and unexpectedly crashing/quitting with a known and tested config file is not good design. BTW I tried to "recreate" those config files from scratch in 10.9, and it still crashes on a sync job which 10.0 handles quite easily and without crashes.

- The progress window on version 10.9 is tiny compared to version 10.0. If I resize it, my size is not saved, so every time I start the software, the progress window is tiny and useless to watch progress stats.

- Any overwrite operations icons should be RED in color, not blue, green! A file overwrite operation, no matter what configuration is selected, must always stand out to the user!!!

- No matter what I do, there is no way to completely block FFS from checking for updates. Even if I say "do not check for updates", there is a BLOCKING software check for notification. I want to never have the software check for updates, or even show me any reminders, if modern versions are buggy!

- File moved detection, no matter what is claimed, has never worked reliably. Most of my filesystem operations are file/folder moves. This software has never been reliable to use file/folder renaming/movement instead of wasteful copy-delete/archive operations on what was really just a renamed directory. I clog up my versioning folder with these stupid copies.

Sorry, but I will stick to tried and tested 10.0 until these critical errors are resolved. I care NOT about "new features" if software keeps crashing on me on very simple tasks and operations!!!

Custom .desktop file would look like the following:
#!/usr/bin/env xdg-open
[Desktop Entry]
Exec=/home/linux/Documents/FreeFileSync_10.9/FreeFileSync
Icon=/home/linux/Documents/FreeFileSync_10.9/FreeFileSync.png
Type=Application
Terminal=false
Name=FreeFileSync 10.9

Developer: Linux version of FFS should come with FreeFileSync.png and this (or a better, much fuller https://linuxcritic.wordpress.com/2010/04/07/anatomy-of-a-desktop-file/ ) version of the .desktop file both included INSIDE the program folder, for Linux users of your software to use. Otherwise, we get "plain", no-icon-no-logo icons, while Window$ users get the green arrows icon.

[Zenju]

I think you need to pause pushing out "features" all the time, and fix the big issues.

Interesting. I view FFS as essentially bug-free. Certainly on Windows, and regarding Linux/macOS at least judging by the user feedback, which is actually very little. And you can only fix what you know about...

After version 10.0, I can no longer launch FreeFileSync from a desktop symlink created by right-clicking on the software, and then moving the symlink to the desktop. But I can launch it by clicking on the binary/executable itself.

This has never been a feature, and it's more accidental if it ever worked.
I don't think you can generally expect symlinking to executables to work in Linux for applications that consist of more than one file, such as FreeFileSync.
But it's not difficult to support either, and may be useful since Linux lacks an easy-to-use concept such as shell links on Windows.
I've added support for the next version, you can test it with the beta:
https://www.mediafire.com/file/k857p31dw7sz0dj/FreeFileSync_10.11_beta_Linux.tar.gz/file

After version 10.0, some versions will plain never launch even from the binary, or they crash immediately

The FFS package now contains multiple binaries and selects the right one via a launcher process. Since there are lots of different Linux systems, it's quite likely there are problems, but it's also likely that they can be solved.
The first step to diagnose these issues is to run via the command line and see if there are any error messages.

After version 10.0, program is very likely to crash while I am using configuration files from an older (tried and tested) 10.0 installation.

Sounds very strange that a crash could be dependent from the format of the config file. Usually FFS would show an error, but who knows maybe we have an uncaught exception here.
The process of diagnosing remote crashes on Linux is extremely tedious (viewtopic.php?t=6168) therefore as much upfront investigation as possible should be done beforehand.

The progress window on version 10.9 is tiny compared to version 10.0.

Okay, but no such problem with the lastest version 10.10, right?

Any overwrite operations icons should be RED in color, not blue, green! A file overwrite operation, no matter what configuration is selected, must always stand out to the user!!!

I disagree: Overwriting a file is no more dangerous than say deleting it. Or to put it differently: almost everything FFS does is dangerous if you mess up the configuration.

No matter what I do, there is no way to completely block FFS from checking for updates.

With "blocking" I assume you mean the popup dialog that informs about the new version? The update check itself should run asynchronously and does not block.

File moved detection, no matter what is claimed, has never worked reliably.

This is not FFS's fault but simply due to the fact that not all file systems support file ids, and those that do support are sometimes not reliable in their handling, most notably FAT.
FFS makes the best of the situation by also supporting cases where one side supports file ids, but the other does not. This is as good as it can get, but admittedly it has the "price" of appearing to the user to work "unreliably" in certain scenarios. Still I believe this is better than not having partial move detection, even if non-function is incorrectly attributed to FFS.

Sorry, but I will stick to tried and tested 10.0 until these critical errors are resolved. I care NOT about "new features" if software keeps crashing on me on very simple tasks and operations!!!

I hope I've made it clear that none of these issues are due to FFS's quality "degrading" or something like that. Practically there is never a reason not to update as stabilty is increasing. But in the case of Linux this also requires user feedback such as yours.

Developer: Linux version of FFS should come with FreeFileSync.png and this (or a better, much fuller https://linuxcritic.wordpress.com/2010/04/07/anatomy-of-a-desktop-file/ ) version of the .desktop file both included INSIDE the program folder, for Linux users of your software to use. Otherwise, we get "plain", no-icon-no-logo icons, while Window$ users get the green arrows icon.

The problem with desktop files is that their target path has to be absolute, but FFS doesn't impose any fixed path where the app should be placed. So I'm not sure how much sense it would make to ship with an "almost-complete" desktop file, that has all fields filled except for the icon and executable path. Most likely this will raise more questions of users wondering, why the desktop file is "not working" by default.


Great feedback overall! It's still a bit too much to handle in a single thread and would have been worth multiple forum posts.

[bgstack15]

@Zenju, every distro I've ever worked with has supported the hicolor icon theme. I guess a distro could ignore it too; it's really just a directory in a particular location.

The hicolor icon theme exists so that packages and applications can always place their main icons somewhere. Please check out your local /usr/share/icons/hicolor directory and layout. There's a 48x48/apps/ location where a single icon goes. For some reason, 48 seems to be the default. If there's only one published icon in a bitmap format of any kind, it is 48x48. For a svg, you can use /usr/share/icons/hicolor/scalable/apps/. So that solves the placement for icons.

About the desktop file requiring full paths, I would agree for the most part, when discussing the Exec=. I understand that the $PATH is respected when resolving the executable name, i.e., "FreeFileSync" should work if FreeFileSync binary exists in /usr/bin.

However, the Icon= entry can be just a single object name, such as "FreeFileSync" if a FreeFileSync.png exists in /usr/share/icons/hicolor/48x48/apps/ or a FreeFileSync.svg exists in /usr/share/icons/hicolor/scalable/. Or for user-only installations, you can use ~/.local/share/icons/ and its children. Otherwise, Icon= must also be a full path name.

[publicemaildump751]

I think you need to pause pushing out "features" all the time, and fix the big issues.

Interesting. I view FFS as essentially bug-free. Certainly on Windows, and regarding Linux/macOS at least judging by the user feedback, which is actually very little. And you can only fix what you know about...

Zenju, Well this is why I am letting you know. I donated twice, used your software for years, honestly your software contribution to my backup strategy is hundreds of dollars... But you see why I am dissapointed that I can't stop using 10.0 because I get different issues every time I try to upgrade... But like I said somehow you have the FASTEST release cycle among any other single software I know.

After version 10.0, I can no longer launch FreeFileSync from a desktop symlink created by right-clicking on the software, and then moving the symlink to the desktop. But I can launch it by clicking on the binary/executable itself.

This has never been a feature, and it's more accidental if it ever worked.
I don't think you can generally expect symlinking to executables to work in Linux for applications that consist of more than one file, such as FreeFileSync.
But it's not difficult to support either, and may be useful since Linux lacks an easy-to-use concept such as shell links on Windows.
I've added support for the next version, you can test it with the beta:
https://www.mediafire.com/file/k857p31dw7sz0dj/FreeFileSync_10.11_beta_Linux.tar.gz/file

Ah yes, I did notice the several binaries. And the time around which symlinks stopped working matches in general the time when you switched from pre-built binaries for different distributions to a single release. And like I said some other software like Bleachbit seems to also not be able to work from a desktop symlink. Well, do please add the icon and a sample .desktop file for Linux users within the program folder. Those .desktop files can get VERY sophisticated...
I myself am still learning Linux and do not at all consider myself an expert like with Windows, which I have now abandoned.

After version 10.0, some versions will plain never launch even from the binary, or they crash immediately

The FFS package now contains multiple binaries and selects the right one via a launcher process. Since there are lots of different Linux systems, it's quite likely there are problems, but it's also likely that they can be solved.
The first step to diagnose these issues is to run via the command line and see if there are any error messages.

For other users reading this, open CLI in directory where FFS is installed and in CLI (bash, etc), run ./FreeFileSync. Keep CLI open, do not close it. If FFS crashes, some output will be placed on CLI.
Zenju, well it works for 10.9. I don't have the time at the moment to run some other release from 10.1 to 10.8. If it breaks again, I will update the post.

After version 10.0, program is very likely to crash while I am using configuration files from an older (tried and tested) 10.0 installation.

Sounds very strange that a crash could be dependent from the format of the config file. Usually FFS would show an error, but who knows maybe we have an uncaught exception here.
The process of diagnosing remote crashes on Linux is extremely tedious (viewtopic.php?t=6168) therefore as much upfront investigation as possible should be done beforehand.

Well, unfortunately it seems to be FILE / stream dependent because it seems to work if I have recently synced my Linux EXT4 home directory to external EXT4 partition, but crashes again after some time when more files get out of sync. Unfortunately, it may be difficult for me to figure out which file / setting is causing this as I have little time at the moment. I will keep considering to evaluate this at depth. But once again, my trusty 10.0 is trusted to not crash...
OK, CLI reports the following error:
Segmentation fault (core dumped)
Which is not very helpful.

The progress window on version 10.9 is tiny compared to version 10.0.

Okay, but no such problem with the latest version 10.10, right?

No version 10.10 (just tested) still has the much smaller window size compared to 10.0, and if resized, the new size is not saved.

Any overwrite operations icons should be RED in color, not blue, green! A file overwrite operation, no matter what configuration is selected, must always stand out to the user!!!

I disagree: Overwriting a file is no more dangerous than say deleting it. Or to put it differently: almost everything FFS does is dangerous if you mess up the configuration.

Hmm, maybe for version 20.0 add ability to select color of each type of icon?

No matter what I do, there is no way to completely block FFS from checking for updates.

With "blocking" I assume you mean the popup dialog that informs about the new version? The update check itself should run asynchronously and does not block.

It is blocking because there is up to 3 seconds pause on slow Internet connection where it won't run a sync job while checking for an update. At least with 10.0, even if I keep unchecking the Help option to check, it seems to re-enable itself??? Frankly I think that if I uncheck "check for updates periodically", even the already-known notification of new version available should not be shown.

UPDATE: I don't know why, I just figured out this is how it happens (Linux, multiple versions in multiple directories separate from each other):
Run 10.10, say. If any GUI prompts appear to download new version, dismiss them. Uncheck to search for updates. Close, relaunch: option not checked.
Run 10.9, say. Uncheck to search for updates.
If I run 10.10 again, option is checked again. If newer versions are available, GUI prompt to Download is displayed again, even if previously dismissed.

The two versions in separate directories are seeing each other or writing to a shared config file???

File moved detection, no matter what is claimed, has never worked reliably.

This is not FFS's fault but simply due to the fact that not all file systems support file ids, and those that do support are sometimes not reliable in their handling, most notably FAT.
FFS makes the best of the situation by also supporting cases where one side supports file ids, but the other does not. This is as good as it can get, but admittedly it has the "price" of appearing to the user to work "unreliably" in certain scenarios. Still I believe this is better than not having partial move detection, even if non-function is incorrectly attributed to FFS.

I was confused why it was claimed that this feature was added, but was not indeed working. As you see, it is very wasteful to continually create copies of moved files (I don't want to think now that some time in the future I will have to "clean up" a huge directory of many, many copies of data I actually safely have). Thank you for clarifying it.

Sorry, but I will stick to tried and tested 10.0 until these critical errors are resolved. I care NOT about "new features" if software keeps crashing on me on very simple tasks and operations!!!

I hope I've made it clear that none of these issues are due to FFS's quality "degrading" or something like that. Practically there is never a reason not to update as stability is increasing. But in the case of Linux this also requires user feedback such as yours.

I will say right now that I use this software daily for multiple backup scenarios and this software has TREMENDOUS value, power, and ease of use, even if it was sold for $40. But it is FREE.
Zenju, just please NEVER EVER add PUA back into Windows installer. At my work I have to please the IT gods to give me admin access but if EVER an EXE with PUA (not even a virus! even if I don't ever run the executable!) is found on my computer (old HD files, USB stick contents, browser downloads, etc) that has PUA, I IMMEDIATELY lose admin access to the computer, and it is super hard to get it back.

Developer: Linux version of FFS should come with FreeFileSync.png and this (or a better, much fuller https://linuxcritic.wordpress.com/2010/04/07/anatomy-of-a-desktop-file/ ) version of the .desktop file both included INSIDE the program folder, for Linux users of your software to use. Otherwise, we get "plain", no-icon-no-logo icons, while Window$ users get the green arrows icon.

The problem with desktop files is that their target path has to be absolute, but FFS doesn't impose any fixed path where the app should be placed. So I'm not sure how much sense it would make to ship with an "almost-complete" desktop file, that has all fields filled except for the icon and executable path. Most likely this will raise more questions of users wondering, why the desktop file is "not working" by default.

It can be argued both ways. Indeed, there is no fixed location where I place FFS. But the fact that I can have many, many versions of same software side by side on Linux is amazing.

"How to start FFS from desktop on Linux" FAQ article on your website, with a tutorial / sample on how to create a .desktop file, would be a good alternate idea to including a generic .desktop file inside the release.

Great feedback overall! It's still a bit too much to handle in a single thread and would have been worth multiple forum posts.

Sorry, my personal time is extremely constrained. I work two jobs... So I put everything here instead of bug reports, etc. Thank you for responding, I was counting on that...

[publicemaildump751]

I caught an example of a job which 10.0 could handle but 10.9-10.10 cannot !!! As you see, it is supposed to delete (actually, move to archival folder) these files.

Is it the plus signs in filenames??? Or folder/file total path length limitation???

Archival folder path is
/media/linux/LinuxFSBackup/LinuxGamingDesktopHomeDirectoryBackupDeleted

See attachment!

[Zenju]

Well, do please add the icon and a sample .desktop file for Linux users within the program folder.

Ideally, this would be the OS's job, e.g. the user would just start FFS, and then pin the currently running process to the dash/sidebar. I know this used to work in older Ubuntu versions, but for some reason is not possible anymore in the more recent ones, and also not possible on other Linux distributions. Anyway, I consider it FFS's job to always find practical solutions rather than whine about unfortunate things it has no influence over.
I've added the two example .desktop files, hoping this will help Linux users:
https://www.mediafire.com/file/g773vnnsbp7wtd1/FreeFileSync_10.11_Linux.tar.gz

No version 10.10 (just tested) still has the much smaller window size compared to 10.0, and if resized, the new size is not saved.

Do you have a screenshot? The progress dialog looks fine in my tests. Remembering the dialog size was a planned feature, but nobody asked about it as of late. Maybe even you wouldn't need it, because it seems the real issue is the default size.

Hmm, maybe for version 20.0 add ability to select color of each type of icon?

Not sure, there seems very little demand for this kind of customization.

It is blocking because there is up to 3 seconds pause on slow Internet connection

Another reason to update: This was fixed in FFS 10.1 ;)

The two versions in separate directories are seeing each other or writing to a shared config file???

Indeed, FFS uses $XDG_CONFIG_HOME: viewtopic.php?t=5750&p=19045#p19056

I was confused why it was claimed that this feature was added, but was not indeed working.

You're probably not the only one. FFS currently does not make it transparent when there are issues regarding file ids: it just silently falls back to "copy + delete". Perhaps it should show a warning, if file ids could not be retrieved. This warning however has the potential to annoy users who don't care about file move detection. TBD.

Zenju, just please NEVER EVER add PUA back into Windows installer.

I think this chapter can be closed for good. Still, it was necessary at the time to bridge the financing until I came up with an alternative, which is the current 100% donation-based system. Otherwise, FreeFileSync probably would not exist anymore post 2012.

I caught an example of a job which 10.0 could handle but 10.9-10.10 cannot !!! As you see, it is supposed to delete (actually, move to archival folder) these files.

With "not handle" I assume you mean "crash".

supposed to delete (actually, move to archival folder) these files.
[...]
Archival folder path is
/media/linux/LinuxFSBackup/LinuxGamingDesktopHomeDirectoryBackupDeleted

I don't understand your meaning of "Archival". From the screenshot it seems this is the target folder of the mirror sync. I believe you also may have set up versioning for handling of deleted files, and it almost sounds as if you have set this versioning folder to the same path as the target folder?