Author Topic: Unison Synchronization  (Read 1382 times)

0 Members and 1 Guest are viewing this topic.

dubb

  • Swamp Rat
  • Posts: 1059
Unison Synchronization
« on: December 08, 2017, 03:06:28 PM »
In response to John Kaul (Se7en) suggestion to use Unison.

No problem.

Calling Unison from within lisp should be fairly straightforward; you could even maintain the .prf files all from within lisp and/or only call the commands necessary instead of all, every time. Might turn out very slick.

I have finally gotten around to testing unison. I do like the way it works and I happen to like using it. However there are so many options I don't know what to do in a case where a sub directory does not exist. For example. If root0 does not contain a folder that root1 has. Unison won't mirror it after executing unison.

Utilzing
Code: [Select]
repeat=watch is a nice feature option.


Executing unison. Is there a way to specify an absolute path for the .prf file or does it only point to the roaming profile in the .unison directory?
Code: [Select]
@echo off
call "D:\test\Unison\unison 2.48.4 text.exe" sync-test

pause

prf file
Code: [Select]
# Unison preferences file
# This file will preform a sync on D:/test/local/
#
# Last Updated: 01.01.99

#---[ Root ]------------------------------------------------------------
root = D:/test/server/
root = D:/test/local/

#---[ Paths ]-----------------------------------------------------------
# Paths to synchronize
path = CAD

#---[ Options ]---------------------------------------------------------
batch = true
confirmbigdel = false
repeat = watch

#---[ Ignore ]----------------------------------------------------------

ignore = Path */Temp

ignore = Name *.tmp
ignore = Name *.example
ignore = Name *.zip

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9238
Re: Unison Synchronization
« Reply #1 on: December 08, 2017, 04:04:26 PM »
PRF files should stay local. I would like them to be able to be hosted elsewhere as well but I can see the argument why they are where they are.

root1 should mirror back to root0 if the folder in root1 was created after the initial sync. If the folder root1 was already populated before the initial sync then I imagine you'd run into problems like this. Have you tried killing root1 altogether and re-run the sync?
“Common sense is not so common.” ~Voltaire

--> Donate to TheSwamp.org <--

dubb

  • Swamp Rat
  • Posts: 1059
Re: Unison Synchronization
« Reply #2 on: December 08, 2017, 04:15:00 PM »
PRF files should stay local. I would like them to be able to be hosted elsewhere as well but I can see the argument why they are where they are.

root1 should mirror back to root0 if the folder in root1 was created after the initial sync. If the folder root1 was already populated before the initial sync then I imagine you'd run into problems like this. Have you tried killing root1 altogether and re-run the sync?

It worked the way you suggested. Thanks.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9238
Re: Unison Synchronization
« Reply #3 on: December 08, 2017, 04:19:18 PM »
Quick isn't it?
“Common sense is not so common.” ~Voltaire

--> Donate to TheSwamp.org <--

dubb

  • Swamp Rat
  • Posts: 1059
Re: Unison Synchronization
« Reply #4 on: December 08, 2017, 04:54:15 PM »
Quick isn't it?
Yes, it was rather quick.
Next, will need to put the batch file as a start up program. I'm thinking about scripting something in autolisp to copy prf files into C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
It worked for myself.
To make the command prompt window less, I searched around and found that I need a vbs script
Code: [Select]
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run chr(34) & "D:\test\sync-cad.bat" & Chr(34), 0
Set WshShell = Nothing


dubb

  • Swamp Rat
  • Posts: 1059
Re: Unison Synchronization
« Reply #5 on: December 12, 2017, 05:51:44 PM »
Ok, my final setup. An AutoCAD user would have to run this file once and it will copy prf and vbs files to their local machine. The server would need the unison executables.
Code: [Select]
;;new unison sync
(defun sync (opt / app prf)
;set app and prf
(setq app (strcat "C:\\Users\\"(getvar "loginname")"\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\sync.vbs"))
(setq prf (strcat "C:\\Users\\"(getvar "loginname")"\\.unison\\sync.prf"))
(cond 
;update unison files
  ((= opt u)
   ;kill the unison service
  (command "shell" "taskkill /f /im \"unison 2.48.4 text.exe\"")
  (vl-file-delete app)
  (vl-file-delete prf)
  (setq opt n)
  )
  )
  (cond
  ((= opt n)
;Copy vbs script
(if (= nil (findfile app))
  (vl-file-copy "\\\\server\\cad\\Tools\\unison 2.48.4\\supsync.vbs" app)
  (princ "\nPRF Found!")
  )
;copy unison preferences
(if (= nil (findfile prf))
  (vl-file-copy "\\\\server\\cad\\Tools\\unison 2.48.4\\sync.prf" prf)
  (princ "\nPRF Found!")
  )

;start sync if sync hasn't started
(if (and
      (/= nil (findfile app))
(/= nil (findfile prf))
      )
  (princ "\nAll files found")
  (princ "\nFiles are missing")
  )

(startapp "WSCRIPT.EXE" (strcat "\"" app "\""))
   )
  )
(princ)
)

prf file
Code: [Select]
# Unison preferences file
# This file will preform a sync on supdc1
#

# Last Updated: 01.01.99

#---[ Root ]------------------------------------------------------------
root = C:/
root = //server/cad/

#---[ Paths ]-----------------------------------------------------------
# Paths to synchronize
path = Tools

#---[ Options ]---------------------------------------------------------
batch = true
confirmbigdel = false
repeat = watch
logfile = //server/cad/Tools/unison 2.48.4/sync-log.txt
#---[ Ignore ]----------------------------------------------------------

ignore = Path */Temp

ignore = Name *.tmp
ignore = Name *.example
ignore = Name *.zip
ignore = Name *.dwl2
ignore = Name *.dwl

batch file sync.bat
\\server\cad\Tools\unison 2.48.4
Code: [Select]
@echo off
 
call "\\server\cad\Tools\unison 2.48.4\unison 2.48.4 text.exe" sync
 
pause

sync.vbs
C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Code: [Select]
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run chr(34) & "\\server\cad\Tools\unison 2.48.4\sync.bat" & Chr(34), 0
Set WshShell = Nothing

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9238
Re: Unison Synchronization
« Reply #6 on: January 05, 2018, 12:54:06 PM »
So, how is Unison working out for you?
“Common sense is not so common.” ~Voltaire

--> Donate to TheSwamp.org <--

dubb

  • Swamp Rat
  • Posts: 1059
Re: Unison Synchronization
« Reply #7 on: January 11, 2018, 12:07:55 PM »
Unison is working pretty stable.
I have fine tuned the autolisp sync script that handeled the prf file and vbs startup script. Other than that; synchronizing the CAD tools with each and every workstation is seamless.
Reflecting back to the reason why I considered unison. In the event of a server outage or if a draftsman goes offsite with their laptop. The tools that I developed will always remain on their system with or without our local server. Initially when I first started developing CAD tools for our organization all of the customizations relied on the server. Now all of the dependency of external files and scripts are stored locally and backed up to our server. Synchronization development started with robocopy and evolved into using unison since unison has a plethora of useful options I believe it is a much better approach. Thanks for suggesting Unison!
So, how is Unison working out for you?

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9238
Re: Unison Synchronization
« Reply #8 on: January 11, 2018, 12:26:13 PM »
Unison is working pretty stable.
I have fine tuned the autolisp sync script that handeled the prf file and vbs startup script. Other than that; synchronizing the CAD tools with each and every workstation is seamless.
Reflecting back to the reason why I considered unison. In the event of a server outage or if a draftsman goes offsite with their laptop. The tools that I developed will always remain on their system with or without our local server. Initially when I first started developing CAD tools for our organization all of the customizations relied on the server. Now all of the dependency of external files and scripts are stored locally and backed up to our server. Synchronization development started with robocopy and evolved into using unison since unison has a plethora of useful options I believe it is a much better approach. Thanks for suggesting Unison!

You're very welcome. And FWIW, I was in the same position (AKA: I know. And, I'm glad you finally took my suggestion against an overly simplistic "robocopy solution").
“Common sense is not so common.” ~Voltaire

--> Donate to TheSwamp.org <--

dubb

  • Swamp Rat
  • Posts: 1059
Re: Unison Synchronization
« Reply #9 on: January 11, 2018, 01:01:37 PM »
I forget to mention the fact that in our company network environment; regular employees can't install executeables. Which is one of the main hurdles I have to consider when integrating tools of any sort which also affects how its deployed. Thankfully with unison we didn't have to install it on each machine.
You're very welcome. And FWIW, I was in the same position (AKA: I know. And, I'm glad you finally took my suggestion against an overly simplistic "robocopy solution").

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9238
Re: Unison Synchronization
« Reply #10 on: January 11, 2018, 04:09:24 PM »
I forget to mention the fact that in our company network environment; regular employees can't install executeables. Which is one of the main hurdles I have to consider when integrating tools of any sort which also affects how its deployed. Thankfully with unison we didn't have to install it on each machine.
You're very welcome. And FWIW, I was in the same position (AKA: I know. And, I'm glad you finally took my suggestion against an overly simplistic "robocopy solution").

Understood. But normally, that shouldn't stop someone from asking the IT guy if he cant place an executable on the network for you to run.  Not to mention, most, if not all, of the GNU win exes should be the exact same -i.e. run from a network folder just like you are doing with unison now (hence why I believe most people think I am some sort of moron or something when I suggest their usage and they give me that very same response).
 
Check out some of these tools, I use quite a few of these.
http://gnuwin32.sourceforge.net/packages.html
“Common sense is not so common.” ~Voltaire

--> Donate to TheSwamp.org <--

dubb

  • Swamp Rat
  • Posts: 1059
Re: Unison Synchronization
« Reply #11 on: June 27, 2019, 02:43:02 PM »
Hey @John Kaul (Se7en)
Unison keeps making ".unison.tmp" files. Which stalls the unison synchronization. I have tried many settings and none of them work.

My preferences file.

Code: [Select]
# Unison preferences file
# This file will preform a sync on supdc1
#Updated 10/11/18
#prefer = newer option
#ignore = Name *Drawing

# Last Updated: 01.01.99

#---[ Root ]------------------------------------------------------------
root = D:/
root = //server/cad/

#---[ Paths ]-----------------------------------------------------------
# Paths to synchronize
path = SUP Tools

#---[ Options ]---------------------------------------------------------
batch = true
confirmbigdel = false
repeat = watch
copyonconflict = true
prefer = newer
logfile = D:/Tools/unison 2.48.4/sync-log.txt
owner = true
prefer = //server/cad/

#---[ Ignore File Types]----------------------------------------------------------

ignore = Path */Temp
ignore = Name *.tmp
ignore = Name *.example
ignore = Name *.zip
ignore = Name *.exe
ignore = Name *Drawing
ignore = Name *.dwl
ignore = Name *.dwl2
ignore = Name *.atc
ignore = Name */menu/Users


#---[ Ignore Paths]----------------------------------------------------------
ignore = Path */unison*
ignore = Path */Logs

I even went as far as deleting tmp files using the windows bat file up unison startup.

Code: [Select]
@echo off

DEL /S /Q "D:\Tools\*tmp"
DEL /S /Q "\\server\cad\Tools\*tmp"
 
call "D:\Tools\unison 2.48.4\unison 2.48.4 text.exe" sync
 
pause


« Last Edit: June 27, 2019, 02:54:00 PM by dubb »

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9238
Re: Unison Synchronization
« Reply #12 on: June 27, 2019, 03:29:59 PM »
I just started a new job so I am busy setting up my new PC and filling out forms. Sorry, but I probably wont get to this in the next few days.
“Common sense is not so common.” ~Voltaire

--> Donate to TheSwamp.org <--

dubb

  • Swamp Rat
  • Posts: 1059
Re: Unison Synchronization
« Reply #13 on: June 27, 2019, 07:00:20 PM »
I just started a new job so I am busy setting up my new PC and filling out forms. Sorry, but I probably wont get to this in the next few days.

Congrats on the new job! No worries. Its not super priority.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9238
Re: Unison Synchronization
« Reply #14 on: July 03, 2019, 10:16:30 AM »
So from my understanding, these temp files get created because Unison was interrupted. In other words, the tmp files are the applications previous progress, and the application is checking to see if the tmp files match the source, and the destination files and trying to resolve the mess before it starts transferring files around. You could create quite a mess if temp files get created somewhere (they would be potentially propagated everywhere because they exist in some source...ugh!). Do you know if someone stopped Unison?

I like your idea about killing the temp files before the call to unison happens. This may be your only option at this point (if someone has these temp files on their hard drive now).

I'll give this a think and get back to you.
“Common sense is not so common.” ~Voltaire

--> Donate to TheSwamp.org <--