Realtime will not forget deleted FFS batches

[bronowski]

I have set up a Realtime batch to watch a folder using a particular FFS batch.
I made a mistake in the first FFS batch I made, so I deleted this and made
another one, and changed the reference in the Realtime batch to the correct
one.

The Realtime batch, when run, looked for the deleted FFS batch and gave me an
error message as it could not find it.

Fair enough, I supposed the Realtime batches must be somehow tied in to
particular FFS batches, so I deleted that and made another new Realtime batch
to watch the same folder.

But this new Realtime batch also looks for the same deleted FFS batch.

How can I resolve this?

[Zenju]

There are two ways to start RTS, either pass a .ffs_batch file as first
argument, this sets the two parameters "delay" and "command line" to default
values or pass a .ffs_real file which is just an XML which remembers non-
default values for the two parameters. I guess you are probably starting RTS
via a .ffs_real file but have not really updated it, but just changed the
settings shown when RTS is started without arguments.

[bronowski]

Aha! I didn't know it was an XML file.
Here it is:

<?xml version="1.0" encoding="UTF-8"?>
    <FreeFileSync XmlType="REAL">
        <Directories>
            <Item>\\SD30G2\Users\Admin\Documents\Accounts</Item>
        </Directories>
        <Commandline>C:\users\Accounts\Dropbox\Accounts.ffs_batch</Commandline>
        <Delay>10</Delay>
    </FreeFileSync>


This looks complete.

[bronowski]

...and I've also just noticed, that when you draft a set of three FFS files on
the desktop, get them working, move them to a directory, and change the
command line path to that new directory, running the REAL file still looks for
the now non-existent files on the desktop.

This is surely a flaw which needs to be addressed.

[Zenju]

> This looks complete.


Can you make sure this is indeed the file that is passed as first command line
parameter to RTS?


> running the REAL file still looks for the now non-existent files on the
desktop.


Did you save the .ffs_real file?

[bronowski]

I only have one command line parameter in the REAL file, that is the path to
the batch file. All three files, GUI, BATCH and REAL were made and saved to
the desktop and seen to be working by placing some new files in the source
directory and seeing that they were backed up to the target.
Then I copied all three files to a directory. The GUI and BATCH files contain
no references to their location, and so were unchanged. I confirmed that this
was so as follows:
First: Moved only the GUI and BATCH files to the directory, leaving the REAL
file on the desktop, and ran the REAL file.
Result: Working properly.
Second: Moved the REAL file to the directory. Edited the command line to
replace this line that was there:


C:\users\Accounts\Desktop\Accounts.ffs_batch


with this new line:


C:\users\Accounts\Dropbox\Accounts.ffs_batch


Result:
Windows shows an alert saying this:



Invalid command line:
File: C:\users\Accounts\Desktop\Accounts.ffs_batch
Arg:
Windows error code 2: The system cannot find the file specified.

[Zenju]

Did you restart RealtimeSync after you changed the .ffs_real file? The
configuration is only read once upon startup, maybe this is the problem here.

[bronowski]

Yes, certainly, many times.
May I ask where RealTimeSync stores its configuration (such as, which batch
files are attached to what directories) so that I can check that.

[Zenju]

If you have installed FreeFileSync locally, then the RealtimeSync
configuration is stored under %appdata%\FreeFileSync, else it's in the
installation directory. However this configuration is only used if you start
RealtimeSync without passing a different configuration as first command line
argument.


> First: Moved only the GUI and BATCH files to the directory, leaving the REAL
file on the desktop, and ran the REAL file.
Result: Working properly.


The .ffs_real file is referencing the .ffs_batch file on the desktop, but you
have moved latter away. It's impossible the .ffs_real file is still working.

[bronowski]

It worked because at that moment there were still original copies of the files
on the desktop, ie. my MOVE was actually a COPY.

I have worked around the problem by doing a disk cleanup, deleting all
temporary files, this makes any existing REAL files that have been moved work
properly. From now on, I will make all new files in the directories they are
intended to be in, so the problem will not recur.

Many thanks for your kind help.