Donation Edition stops working!!!

[cookie170]

Hi!

I'm using a donation edition of FreeFileSync and get complains that I had it
installed on 10 devices. But if you look closely, it's ten times the same
device:

AW 13.4 20XW0055G -- LENOVO

I guess the trouble comes from my OS Tumbleweed, which changes nearly every
day. Your database seems to contain lines like " AW 13.3 openSUSE 20240214
20XW0055GE – LENOVO" and the date after openSUSE changes frequently.

Now FreeFileSync won't start anymore. I wrote an E-Mail yesterday, but have not received an answer.

I'll go for a better software that doesn't stop me working for ridiculous reasons.

I reported this issue three years ago here: viewtopic.php?p=42738

Nothing happened.

[Zenju]

Is there some way to have openSUSE not change network MAC addresses after each start? If not, I can refund your donation.

[cookie170]

I've asked a question about MAC addresses at forums.opensuse.org.

Maybe you can take more data into account when checking for different installations. Obviously the product name -- in my case "20XW0055GE" -- is highly significant, but your algorithm doesn't seem to take note of that.

Or simply trust me.

[xCSxXenon]

Or simply trust me.

Ha That's rich, end users can never be trusted lol
Any suggestions on what other data could be collected to uniquely identify a device without being too intrusive to the end user?
Also "20XW0055GE" isn't unique, it's a product ID for the device model so thousands of people share it.

[cookie170]

Or simply trust me.

Ha That's rich, end users can never be trusted lol
Any suggestions on what other data could be collected to uniquely identify a device without being too intrusive to the end user?
Also "20XW0055GE" isn't unique, it's a product ID for the device model so thousands of people share it.

See here: https://www.statista.com/statistics/203691/global-unit-shipments-of-notebooks/ I bought my notebook in 2021 so it is one of 246 m pieces. The trouble are probably Apple Notebooks: not many different types, but sold in huge numbers and all have the same OS.

I don't think there is an easy solution. Other software places a cookie somewhere in the users data tree oder in the root tree, but of course there is software like inotify-tools that shows immediately the place of such a cookie.

You probably can't collect the Windows key from the BIOS or something similar from Apple Hardware: You'd run into data protection issues without users consent.

So there is no other way: trust in your users. If you don't, they will stop using your software and switch to syncthing, unison or a little more sophisticated rsync-bashscript.

[xCSxXenon]

Good luck with those other options that lack the features of FFS ¯\_(ツ)_/¯

[JanW]

I moved to a new laptop with OpenSuse Tumbleweed and observe the same behavior. So far this has not resulted in me being blocked from using FFS (there were 5 entries for my license today). As @cookie170 noted above, the issue here is that the OS version is included in the database entry, and the Tumbleweed OS version changes about 5-6 times per week because it's a rolling-release distro. Would it be too complicated to include logic that removes recording the OS version specifically for OpenSuse Tumbleweed, or better, all rolling-release distros that report their version number this way ? I never used other rolling-release distros, so I don't know if they behave the same way.

I can see the use to include OS version in the database for other systems - to better identify a single machine, it is useful to know if a computer runs Windows 10 or Windows 11, and similarly for Ubuntu or MacOS, since these versions change infrequently. But for Tumbleweed the version number is simply not informative to identify a device.

[Tesseract2]

If you go to the link in the 'Thank you' email when you first donated, the page tells you how many devices the software is installed on. Click on this button and you get a list of the devices, and you can remove each one that is redundant. While this may not be the ultimate answer to your issue, I think you'll find it a lot easier than migrating to a more costly and/or inferior solution.
There's probably an easier/more direct way to get to the relevant page than digging out an email from several years ago; if anyone has the method it would be great to know. Anyway, once you've visited, you can always bookmark it.

[Plerry]

> There's probably an easier/more direct way ...

In the GUI of the installed FFS donation edition, go to Help / Check for updates now.
The screen that appears has a button "Home page".

[cookie170]

If you go to the link in the 'Thank you' email when you first donated, the page tells you how many devices the software is installed on. Click on this button and you get a list of the devices, and you can remove each one that is redundant. While this may not be the ultimate answer to your issue, I think you'll find it a lot easier than migrating to a more costly and/or inferior solution.
There's probably an easier/more direct way to get to the relevant page than digging out an email from several years ago; if anyone has the method it would be great to know. Anyway, once you've visited, you can always bookmark it.

Unfortunately that doesn't work if you have lots of updates that change the OS identity or even the used MAC addresses. Tumbleweed by openSUSE is always restructuring, but recently they moved to RPM 4.19 which lead to a replacement of all installed rpm-packages. Now, only a couple of days later Tumbleweed moves to RPM 4.20, same replacement of all rpm-packages. So the website of FreeFileSync lists 10 (!) Computers in my case, on which the software was installed and because that came in a couple of days, you can't remove them. I get the error message: "The device cannot be removed before March 17th, 2024."

[cookie170]

Is there some way to have openSUSE not change network MAC addresses after each start? If not, I can refund your donation.

What about changing the time after which a device on which FreeFileSync seems to have been installed, can be removed? For me it would be no problem to remove every device except for the newest on your website, https://freefilesync.org/thank-you.php .

There are already ten devices listed, although I'm only using my notebook...

I tracked the MAC addresses during the last days using

ip link


:

ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 08:6a:c5:4a:8f:99 brd ff:ff:ff:ff:ff:ff
4: wwan0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/[519]

ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s13f0u3u3c2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 00:50:b6:f5:a5:2c brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DORMANT group default qlen 1000
    link/ether be:0d:e1:47:7c:2b brd ff:ff:ff:ff:ff:ff permaddr 08:6a:c5:4a:8f:99
4: wwan0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/[519]
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/none

ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 08:6a:c5:4a:8f:99 brd ff:ff:ff:ff:ff:ff
4: wwan0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/[519]
9: enp0s20f0u1c2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether f8:e4:3b:86:9c:05 brd ff:ff:ff:ff:ff:ff

ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s20f0u1c2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether f8:e4:3b:86:9c:05 brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 08:6a:c5:4a:8f:99 brd ff:ff:ff:ff:ff:ff
4: wwan0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/[519]

ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s20f0u1c2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether f8:e4:3b:86:9c:05 brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 08:6a:c5:4a:8f:99 brd ff:ff:ff:ff:ff:ff
4: wwan0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/[519]

   
    ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 08:6a:c5:4a:8f:99 brd ff:ff:ff:ff:ff:ff
4: wwan0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/[519]
5: enp0s13f0u3u3c2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:50:b6:f5:a5:2c brd ff:ff:ff:ff:ff:ff

localhost:/home/AW # ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 08:6a:c5:4a:8f:99 brd ff:ff:ff:ff:ff:ff
4: wwan0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/[519]
5: enp0s13f0u3u3c2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:b6:f5:a5:2c brd ff:ff:ff:ff:ff:ff


I've noticed again ten installations are listed on https://freefilesync.org/thank-you.php and I can delete none, always getting a message "The device cannot be removed before March 17th, 2024."

[JanW]

"The device cannot be removed before March 17th, 2024."

Same here. There seems to be a two week timeout before a device can be removed. Which would be reasonable if the device was identified correctly. Instead of reducing the timeout and requiring manual intervention by the user several times per week (or per month depending on the frequency at which FFS is used), I think finding a way to correctly identify each device would be the better solution. Possibly not easy though, I admit...