FreeFileSync Forum

There are many options, heres a few: 1) Sync D:\ to its own folder on Z:\, such as "Z:\D Backup\" 2) Change sync method to 'update' so files that exist only on the right side don't get deleted 3) Add local exclusion filters to the "D to Z" pair that exclude "\Desktop\" and "\Documents" There are ...

Any FFS jobs that involve that location? Maybe it's getting removed that way?
Any scheduled Taks / Crom jobs?

See system logs and 'systemctl status poweroff.target' for details.

Seems like it might tell you there

Because The "Desktop" and "Documents" folders do not exist in D:\
You are telling FFS to mirror D:\ to Z:\
Since those folders don't exist in D:\ and you are telling FFS to make Z:\ look exactly like D:\, it does exactly that

But the next day or after a few days, for example 5 days, it happens again. And now it happens to me every day. And I have to reinstall the program every day. That's not a plan. It takes away all credibility. And it's a shame, because the program works well. But then you have to reinstall it every ...

For large amounts of data like that, people start to migrate towards solutions like shipping drives to something like AWS for backup. Back Blaze is another option I've seen around. 8TB+ cloud storage and expensive will always be in the same sentence.

That is correct

Correct, you can't use RTS to monitor a GDrive location. Remove it from the RTS configuration

Because MTP doesn't support it MTP is not the issue, BUT: Google doesn't implement it properly. On some Android phones it works, on others it doesn't, but it isn't a problem with the MTP specification. This is true! For me and many others, it has essentially evolved into an MTP issue for all ...

Deletions before updates/creations Files before folders A to Z (Alphabetical) Not quite true, let me clarify: Deletions before updates/creations "Everything that reduces disk space" before "everything that increases disk space". I.e. deletions, and "overwrites of a big file by a smaller one" happen ...

I don't think so... I am pretty sure FFS uses the cookie/token created via the browser to obtain access. When you sign out, this gets revoked, so FFS can't access it anymore. The dev @Zenju will have to 100% confirm this though

@Zenju There's developments! Maybe this info can help you if you were interested in looking into this?

I'm a highly experienced developer with first class comprehension and communication skills. photon, 16 Sep 2024, 11:07

LOL riiiiight

search.php?keywords=dark
@Zenju Can we just delete duplicate posts from now on?

The only thing you seem to have added is how to get it to start when Windows boots, but that is a Windows-side process.
I'm all for creating clearer/more helpful docs, but I don't see any benefit in anything you've added ¯\_(ツ)_/¯

Because MTP doesn't support it

Deletions before updates/creations
Files before folders
A to Z (Alphabetical)

Seems pretty complete
https://freefilesync.org/manual.php?topic=realtimesync

Is there anything I can do to resolve this issue? dave_m, 13 Sep 2024, 18:47

Nope :c

You can't exclude .ffs_tmp files, they are hard-coded to be included since they are a part of how FFS works.
You need to exclude the file with the actual extension it has:
'D7AAB420-8339-43EA-821A-FD56632F096A_notify.XXXX'
"XXXX" needs to be the extension of the actual file

Flathub isn't an official version so you'll likely need to contact whoever maintains that package
You can try searching the entire volume for that file pretty quickly with Terminal

That said, your dmp file shows that RTS is crashing due to a failed memory allocation of 64 kB. So apparently your system ran out of memory. Using Windbg, I am not getting anything close to that error. It reports: "0xe06d7363 - <Unable to get error code text>" What are you using to analyze the dmp ...

Read the documentation first

Read the documentation first

Can you read?
https://freefilesync.org/manual.php?topic=realtimesync

There is not an MSI. The EXE supports silent installation, is there anything that an MSI would offer that isn't currently available

That dumps produces the same useless info as above lol
Try running a stack trace?
https://freefilesync.org/faq.php#trace

This is correct, GDrive will not work with RTS. granted, RTS doesn't work with the client program either, as you experienced. For what it's worth, I use RTS to monitor OneDrive local directories fine without issue. But yes, a scheduled task is going to be a more reliable option. Since cloud ...

Regardless, the OP is trying to discover data usage in a location that wasn't directly involved in the FFS synchronization in the first place. Yes, this is one of the few non-sync scenarios that FreeFileSync supports: Just select the whole drive on only one side and press "compare". No need to ...