Home → Problems →

shared folder split into separate folders - how to re-merge?

• Edit

Marty

09 Sep, 2022 12:34 PM

My wife and I both use moneydance via a network drive (windows on her side, linux mount on mine).

We just noticed that we are out of sync and from what I can tell, my linux mount failed at one point and it appears that moneydance automatically rebuilt its directory structure in the directory that is normally mounted. I'm not totally certain that this is what happened but it's the only explanation I can come up with.

The end result is that a previously shared folder has now split into two: (1) the network drive that my wife uses, and (2) a new local copy on my desktop that diverged from the network drive some time ago.

Is there any way to manually merge the transaction history on the network drive without having to manually re-enter (a LOT of) transactions? E.g. I see the individual .mdtxn files on each machine, can those simply be copied from my now-local copy to the network folder? Or is there more to it than that?

Thanks!

1. 1 Posted by Marty on 09 Sep, 2022 12:36 PM

   

   Running version 2022.2 (4060) on both computers.

   • Edit

2. 2 Posted by Stuart Beesley ... on 10 Sep, 2022 10:22 AM

   

   That’s a new problem! It might be possible. Do a good BACKUP first!

   As you say that both datasets came out of the same dataset/sync, then encryption should also be the same.

   In theory, if you copy the missing .mdtxn files into the master, it should pick them up and process them. WARNING: the last change wins. So if you both edited a txn then the version in the .mdtxn file you copy from the other dataset will win.

   You might have to rename the .mdtxn files to .txn. I can’t remember.

   So how to do this. As you are using sync you can probably drop into the Dropbox sync shared folder .moneydancesync/loong_number/v3 and see what happens.

   I would have help/console open in parallel and watch the console log

   I would do one file and see if it worked.

   If that fails then put into the dataset/safe/tiksync/out folder

   So how to test one? On the other machine, run toolbox. Advanced mode. Peek at file in sync folder. Select the oldest one. This will show you what txn is within the .mdtxn file. Now check that record out on both copies. Now Copy/drop that file over and see if it updates.

   This is all untested. BACKUP FIRST.

   (not support, just a fellow user)

   • Edit

3. 3 Posted by Stuart Beesley ... on 10 Sep, 2022 10:22 AM

   

   I would also upgrade to 2022.5(4091) on both first!!

   • Edit

4. 4 Posted by Marty on 10 Sep, 2022 01:59 PM

   

   Thanks! Yes, definitely backup up before giving this a try.

   The good news is that I diff'ed the .../v3 directories and there are no conflicts. That is, all of the .mdtxn file names in location A differ from all of the .mdtxn file names in location B. So that's a win.

   I do notice that there are differences between ALL of the files in the (loong_number) directories are different. Those files are:

   • key_test
   • mdata-v1
   • mdsyncinfo.txt
   • tiksyncinfo.txt

   Do you have any idea if those differences will matter? I'm guessing that since they are common filenames that are intended to sync that things will be fine, but that's just a guess.

   One more question: any particular reason you suggest upgrading first, besides just being a good idea to run latest? If there's not a specific benefit for fixing this issue, I might prefer to upgrade afterwards just so there are fewer moving parts here.

   Thanks again!

   • Edit

5. 5 Posted by Stuart Beesley ... on 10 Sep, 2022 02:10 PM

   

   The upgrade is not critical.

   I would expect the date/time to be different but the contents roughly the same. Try opening with texteditor.

   Question. I presume the encryption password to open both datasets is the same (or in fact not set)? Likewise I presume the Dropbox sync password is the same on both?

   I want to revise my suggestion. Only copy Dropbox sync v3 mdtxn files to the other Dropbox sync location (as .txn). Do not mix files between Dropbox sync folder and the tiksync/safe/out dirs (as encryption will be different between both).

   Ie - if you want to use tiksync/safe/in/.mdtxn then put those as .txn into the other’s out and not Dropbox.

   • Edit

6. 6 Posted by Marty on 10 Sep, 2022 03:22 PM

   

   Interesting. What's the difference in meaning between .mdtxn and .txn? On both A and B copies of the shared folder I only have .mdtxn files.

   Also, I don't have any tiksync/* directories anywhere in the shared folder, but I do have them in my local moneydance document directories. My gut tells me that just working with the shared folder is the safest way to go. I don't have any understanding of how tiksync works at all.

   Thanks again, I really appreciate your help!

   • Edit

7. 7 Posted by Stuart Beesley ... on 10 Sep, 2022 04:02 PM

   

   OK, within your xxx.moneydance dataset (folder/package) there will be a folder called /safe/tiksync/out (and also /in )... Anyway, ignore this for now - not needed..

   FYI - MD creates files as .txn and then as soon as it's processed them they get renamed to .mdtxn - but again ignore this - not needed for now...

   Also, I see you are using shared folders... So when I say dropbox above, just substitute the shared folder, it's the same thing/process....

   I have just tested the fix for your problem and it works for me (I rigged up a broken system as you described).... This is all on the presumption that as you say, you had a sync dataset, that the encryption passwords were the same and not changed, that they were joined together by the same shared folder sync, and the shared sync folder passwords were the same and have not been changed...

   So, in simple terms, with help/console open, I copied the missing .mdtxn files from the v3 subdir on system 2 into the same folder in system 1 and hey presto, MD sync picked them up and processed them, and I saw my records update... NOTE: I cannot promise that MD processes the files in true date order.... you will have to try...

   • Edit

8. 8 Posted by Marty on 10 Sep, 2022 05:17 PM

   

   OK cool, that helps a lot. Will pull the trigger shortly. :)

   • Edit

9. 9 Posted by Marty on 10 Sep, 2022 05:50 PM

   

   SUCCESS!

   Just copying the .mdtxn files to the shared folder worked, I can now see all transactions from both A and B machines. Your posts gave me the confidence to try that. I'm quite grateful.

   For anyone who finds this thread later with a similar problem, I also added a step to prevent this from happening again. As noted above, when the network mount on the linux side failed to mount, moneydance created the intermediate directories it needed under the mountpoint, which made them purely local. Now that I have repaired things (and removed the local files), I have also followed the advice I found here so that Moneydance will be unable to write the files locally in the future. For belt-and-suspenders, I'm probably going to start launching moneydance with a script to verify the mount in the first place, too.

   • Edit

10. 10 Posted by Stuart Beesley ... on 11 Sep, 2022 04:50 AM

    

    … any joy?

    • Edit

11. 11 Posted by Stuart Beesley ... on 12 Sep, 2022 05:26 AM

    

    👍 A nice fix and your tip is great!

    • Edit

12. System closed this discussion on 12 Dec, 2022 05:30 AM.