Author Topic: FARR and Dropbox - conflicts... (Read 29,179 times)

Flippertie · « **on:** May 26, 2011, 02:58 PM »

I use dropbox to sync files between PCs. I want to run FARR in portable mode within my dropbox so my aliases and search history etc will sync between PCs

This seems OK if I work on one pc and log off before logging on to another. But if I have sessions on two PCs at the same time I get multiple copies of the ini files labeled as 'conflict' by dropbox.

ie - searchhistory.ini is modified on PC1, Dropbox tries to copy the file to PC2 and fails - because of locking or timestamp differences.

I can live with that - but now I'm getting failure messages when I try to open certain documents: "quickdoclauncher.exe has encountered a problem and needs to close". I'm guessing this is connected as it's only started since I moved FARR into my dropbox.

So my questions:

1 - is there a way I can relocate the searchhistory and launchhistory files (so they're outside the dropbox) but leave the Alias definitions where they are (so they still get synched)?

2 - What should I do about the quickdoclauncher errors? I don't want to wipe everything and start again as I've spent some time setting up aliases etc.

Thanks!

mouser · « **Reply #1 on:** May 26, 2011, 03:40 PM »

quick answer to one part of your question: FARR does not need to use the quickdoclauncher.exe helper; you'll find an option to disable that on the General options tab (uncheck the "Use document launch helper utility").

I say that because FARR does not (should not) be locking any of its settings files.. can you find out more specifically what dropbox is upset about?

One solution for your problem (and someone else mentioned this same problem with dropbox before), is for me to add a setting that says "DO NOT SAVE THE SETTINGS FILE", which you could use on all but one of your pcs? i think that would solve the dropbox conflict errors.. which i assume are being triggered because all copies of the program are trying to save different copies of their file on top of each other. im not sure now that's being detected..

But first it would be really helpful to know what dropbox is detecting specifically that is upsetting it.

Flippertie · « **Reply #2 on:** May 27, 2011, 02:40 AM »

thanks for the quick response Mr Maus.

It seems the quicklauncher prob is only on one of the 3 pc's I've linked to my dropbox. I'll look at the settings and see if I can fix it. Will also see if I can find out more about what the conflicts are . All I see is a file with 'Laptop's conflicted copy {date time}' appended to the filename.

edbro · « **Reply #3 on:** June 22, 2011, 02:54 AM »

The file that gives me trouble with Dropbox is FarrTroubleshooting.log. It is always locked. Is there any way to not log whatever it is supposed to log?

ewemoa · « **Reply #4 on:** June 22, 2011, 03:08 AM »

IIRC, the bottom-most item in FARR's options dialog has to do with the troubleshooting log and it may have a checkbox relating to enabling/disabling logging.

May be that will be of some use.

Flippertie · « **Reply #5 on:** June 22, 2011, 03:38 AM »

Just reporting back:

I unchecked the "Use document launch helper utility" box as suggested and it has resolved the problem opening Office documents etc.

I think the dropbox conflicts come about something like this;

A file exists with identical copies on pcs A and B, and dropbox in the Cloud: Timestamp 10:00 am.

On pc A the file changes and is updated to the cloud with a new timestamp (say 11:00)

Later, on B, Farr updates the timestamp to 12:00. When dropbox (on B) syncs to the Cloud it knows the old stamp (10:00) and the latest (12:00). It finds 11:00 (from A) in the cloud and renames it as 'conflicted' to make way for the upload of the latest version.

It's not a big deal to delete the offending files. Putting a setting to not save the settings file would probably not help. If the setting is stored in the ini file then dropbox will sync it between the pcs. An option to specify the location of the ini files (out side the main installation folder) might work - but is probably not worth yout time - unless other people have the same issue.

mouser · « **Reply #6 on:** June 22, 2011, 08:51 AM »

Quote

An option to specify the location of the ini files (out side the main installation folder) might work - but is probably not worth yout time

you can already do that, just edit the configdir.ini file.

edbro · « **Reply #7 on:** June 23, 2011, 12:26 AM »

Quote from: ewemoa on June 22, 2011, 03:08 AM

IIRC, the bottom-most item in FARR's options dialog has to do with the troubleshooting log and it may have a checkbox relating to enabling/disabling logging.
May be that will be of some use.

Thank you!

mouser · « **Reply #8 on:** June 23, 2011, 01:24 AM »

Quote

The file that gives me trouble with Dropbox is FarrTroubleshooting.log. It is always locked. Is there any way to not log whatever it is supposed to log?
ewemoa says: IIRC, the bottom-most item in FARR's options dialog has to do with the troubleshooting log and it may have a checkbox relating to enabling/disabling logging.

ahhhh.. good find, i didn't even think about that. that makes complete sense that it is giving dropbox trouble.. maybe i should make an option to close it when not needed, rather than keeping it open for thr whole session. adding to my todo list.

lujomu · « **Reply #9 on:** June 23, 2011, 08:53 AM »

I have the same experience with using FARR together with Dropbox. As I have disabled search history, launch history and logging, I only get conflicts for the 'FindAndRunRobot.ini'.

I think the problem is that FARR writes to the ini file upon starting and upon closing. As FARR is one of the apps that is started first and closed last in a session, this might lead to the mentioned conflicts. Rather than putting the ini file outside of the Dropbox (which would actually defeat the purpose of Dropbox, wouldn't it?) an FARR option to not write to the ini file (unintentionally) would be better in my opinion. I already tried to set the ini file to 'read-only' but FARR happily removes the flag upon saving!

mouser · « **Reply #10 on:** June 23, 2011, 09:17 AM »

Quote

an FARR option to not write to the ini file (unintentionally) would be better in my opinion

i will add this.

mouser · « **Reply #11 on:** November 17, 2011, 06:17 PM »

An option to not save the config file except when user goes into options explicitly has been added in the latest version.

sytone · « **Reply #12 on:** November 22, 2011, 12:44 AM »

Looking at the config dir value it would be nice if the computer name was a variable.

Example:
CONFIGDIR=.\%COMPUTERNAME%

Which would become:
<directorywherefarris>\MYCOMPUTERNAME\DonationCoder\AppName\

that way you can have history etc per computer, the only annoying point would be copying the file when you add new aliases.

Thoughts? Any other issues that this would cause?

mouser · « **Reply #13 on:** November 23, 2011, 03:29 AM »

Quote

%COMPUTERNAME%

that's not a bad idea at all. i will try to add it.

DougalS · « **Reply #14 on:** February 15, 2012, 10:23 AM »

I hadn't thought of syncing my aliases via DropBox, but is a good idea.

However I would implement it by leaving FARR installed normally (outside DropBox), and just have it sync the alias files. So long as you aren't editing your alias file on both computers at the same time you won't have a conflict.

Now to make DropBox sync just the alias file, I would use a hard link (file) or symbolic link (folder) in a DropBox folder that points to your alias file/folder. I chose a junction pointing to my Documents\DonationCoder\FindAndRunRobot\AliasGroups\MyCustom folder, so all the files and any custom icons I create are all sync'd. Now, whenever I change any files under that directory tree DropBox sees them and syncs them.

I use the Link Shell Extension to create junctions, available at http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html. With it you can just use right click to select file/folder to link, then again to create linked file/folder where you want it.

Junctions are very handy in Windows 7 (which uses them a lot, how it does all the fancy footwork with the user folders). XP can be risky, because it will delete the parent folder if the junction is deleted using explorer, Vista/7 is smart enough to remove the link and leave the source alone.

Cheers

sytone · « **Reply #15 on:** March 29, 2012, 08:58 PM »

Quote from: mouser on November 23, 2011, 03:29 AM

Quote
%COMPUTERNAME%

that's not a bad idea at all. i will try to add it.

Did you get a chance to add this?

mouser · « **Reply #16 on:** March 30, 2012, 04:26 PM »

Not yet, but I'm going to try to get out an update over the weekend and will add it then.

mouser · « **Reply #17 on:** April 01, 2012, 09:40 AM »

Implemented; will be in update pushed out this weekend.

sytone · « **Reply #18 on:** April 01, 2012, 07:09 PM »

CONFIGDIR = .\%COMPUTERNAME% is in place and working, thanks!

mouser · « **Reply #19 on:** April 01, 2012, 07:10 PM »

great

AJolly · « **Reply #20 on:** August 03, 2022, 11:02 PM »

A decade later, but thanks for .\%COMPUTERNAME% option, it really helps with multiple computer syncing.

The other thought would be if #filecontents worked on ini files, to split out different sections of the config.
HomeAssistant for example uses that structure, it loads the main config file, and then subsections can either be loaded from a second file, or can be in the main config directly:

EX:
[Information]
File Identification=Super Happy Find and Run Robot

[Windows: windows.ini]
[Settings]

(At least for me, what usually changes is the [Windows] subsection of FindAndRunRobot.ini