Auto-Reloads in a Synced Folder, and the Attack of the Errors

[Gammid]

This might be a bit of a niche issue - I'm keeping a self-reloading script in a synced folder, and having some problems with versioning.

Background: I keep one big (alright, only ~5200 lines so far), do-everything script in a synced folder (using BitTorrent Sync Pro) between my home and work computers, so I don't have to write all my neat new functions and hotkeys and things twice. Also for convenience, I use an AutoReload function on a timer to make any changes I write take effect immediately, and the idea is that they then take effect on the other computer too, so I can just jump from one to the other and benefit from the scripts *I* know I wrote, as seamlessly as you please. The AutoReload uses the presence of the file attribute "A" to indicate that it needs to reload (props to dale3h for that solution), so it removes it every time. I don't know if BTSync uses that attribute to recognize the need for an update; I know some backup software does.

So when I write something that causes an error upon reload/run (let's say I forgot to close a paren , I'll get an error message as per the norm, close it, fix my mistake, save again, the script reloads, I go about my day. Now of course, the same thing is happening at the other computer - the A attribute must be re-setting when it copies over - the script file updates, reloads, wham - error message.

This would be fine, BUT - and I can watch this happen when I RDP to the other computer - this apparently stops the file from syncing again until firstly, the error message is closed, AND ONLY AFTER THAT either the file is saved again on the first computer to push through the new version, or the Sync software on the destination computer runs its 10-minute recheck of all files and notices that the timestamp on "that other computer" is more recent than what it has. If the error message stays up though, that script file's timestamp just doesn't change, regardless of how many updates with or without errors have been bouncing around at the other location.

I tend to make dozens of changes a day as ideas occur to me, and there's almost always an error or two as I try new things by the time I switch computers. So if I make a bunch of edits at work, come home, close the offending error message, and 2 minutes later decide to make another edit - I've just made an edit with a later timestamp than the version at work, and all my day's edits are gone. Fortunately, when I twigged to this I tacked a backup function onto the AutoReload that rotates the past 10 iterations of *successful* versions as .txt files in another folder, so if I've the presence of mind, I can grab from there to replace the "active" copy, but I'd rather not have to - automation is the whole idea, after all.

Even worse, occasionally when I save with an error and then immediatelycorrectitandsaveagain, that bad copy will have just enough time to echo across the interwebs to the other computer, but it'll get recognized just slowly enough that the modified timestamp once it arrives and updates will apparently be scantly greater than the timestamp locally where I just re-saved - and the re-save will arrive, or rather try to arrive, at its destination after that error message has already popped up there, so now when the sync software does its next 10 minute recheck, if I haven't already made another change that updates the timestamp again, that bad copy gets sent BACK to where I *just* fixed the damned error. Usually, I've still got it sitting open in Notepad++, so the next time I activate the window, Notepad++ will tell me that another program has changed the file and do I want to reload with THOSE changes, and of course I'll tell it no and then make a quick meaningless change just so MY copy is the latest one; but I shudder to think what may have gotten lost in those 5200+ lines over the past couple years because of this behavior, and what's more it's just annoying.

Does anyone have a more elegant solution for auto-reloading and remaining synced despite errors, or at least a hacky workaround for the same effect? I'm open to ideas for alternate syncing solutions, but I reeeaaally like a few of the features BTSync implements, most notably selective sync placeholder files, unlimited size/# of files/folders/computers, P2P/cloudless communication, a mobile client, and ease of setup; some brief shopping around didn't show me anyone doing all those same things, but I could very well be under-informed.

Code: Select all

(DllCall("GetCommandLine", "str") ~= "i) /r(estart)?(?!\S)") ? ToolTip("Reloaded!",250) 		;Display appropriate greeting for initial launch or reload
					: (%0% = 0 && !InStr(DllCall("GetCommandLine", "str"),"Silent")) ? ToolTip("Hello there!")
Loop, %0%
	{ ScriptParam := %A_Index%
	(ScriptParam = "Backup") ? AHKMainBackup()
	}

SetTimer, AutoReload,1000

AutoReload()
	{ If InStr(FileExist(A_ScriptFullPath), "A")
		{ FileSetAttrib,-A,%A_ScriptFullPath%
		ToolTip("Reloading....",250)
		Run, %A_AhkPath% /restart "%A_ScriptFullPath%" Backup		;Indicate that we're doing a reload, and trigger a backup upon successful launch.
		Sleep, 1000
		ToolTip("Reload failed!")		;Only fires if an error stops the reload
		}
	}

AHKMainBackup()
	{ FileCopy, % A_ScriptFullPath, %BTSyncDir%\Backups\AHK Scripts from %MachineLocation%\%A_ScriptName%, 1
	FileCopy, % A_ScriptFullPath, %BTSyncDir%\Backups\AHK Scripts from %MachineLocation%\%A_ScriptName%_%A_Now%.txt, 1
	Loop, Files, %BTSyncDir%\Backups\AHK Scripts from %MachineLocation%\%A_ScriptName%_*.txt
		OldFiles .= "`n" . A_LoopFileLongPath
	Sort, OldFiles, R					;start from greatest/most recent timestamp
	Loop, parse, OldFiles, `n
		IfGreater, A_Index, 10,		FileRecycle, % A_LoopField			;keep only 10 most recent files, delete the rest
	ToolTip("Script updated & backed up!",250)
	}

[timelizards]

do

Code: Select all

try {
}

and

Code: Select all

catch {
}

statements prevent the errors? have the catch statement only display a msg if you are physically at the computer. i wasnt able to visualize the whole issue you described, i guess im hoping if the errors just dont come up, you can resync the new file appropriately.

[waetherman]

Well it's a typical scenario where if you break an app that auto-updates itself, it may no longer auto-update until fixed manually. That's why you should check an update before sending it to clients.

You could have an updater script, which doesn't change, that updates the updated script which keeps changing.

[Gammid]

timelizards,
I probably should be using try/catch blocks in general, but that wouldn't solve my issue. What I'm referring to is general coding errors, and AHK's built-in error messages at runtime that tell you you did something wrong, like an invalid character in a variable name, or an unexpected close bracket, etc.

waetherman,
Moving the auto-reload into an external script is probably what I'll end up doing - I was just hoping for something I could toss into the main script and keep my nice all-in-one. The fewer things in my system tray the better, and all that. Ah, well.

Thanks for your replies!

[Gammid]

Well, that didn't work. I removed the AutoReload timer from the main script and copied the relevant functions out to another script that I ran independent of the main script, and I'm still seeing the same behavior: while the error message is up, the "file modified" timestamp doesn't change, and it still doesn't change right away after clearing the error message.

Interestingly though, when I decided to take a look at the hidden .sync folder that BTSync keeps, it appears that regardless of whether the AutoReload function is operating in the main script or in the "spin-off", the file IS actually getting picked up by the Sync app - it's just hanging around as a temporary file in the .sync folder, waiting until the script file isn't involved in an active process (the error message). Still the same behavior though - the temp file won't replace the real file until the next 10-minute "full recheck" after the error message is cleared.

Even more interesting: after saving an errored version at work and letting it sync across to home and pop up the error message, I decided to Exit the script at home from the systray. The error message stayed up, belonging to the AutoHotkey.exe rather than the script itself, and when I then saved an error-less version at work to sync back across, all the same things happened - a temporary file was created, the main file wasn't replaced, and when I closed the error message, still nothing.

So the problem appears to be that while an error message borne of the script is up, that file is considered by the Sync app to be locked by AutoHotkey.exe, and it won't recheck to see if it's unlocked until the next "full recheck" - all of which makes perfect sense, it just doesn't mesh with my desires for this particular script.

I suppose I could make the fail condition/the last part of the AutoReload create a one-off script that would then sync over, hit OK on the error message if the machine the one-off is running on isn't the machine that made that one-off, delete itself and ExitApp. Then put a timer on the main script that looks for that one-off file and runs it if it's there, since the error message doesn't prevent that script from running the timers, hotkeys, etc that it's already got, just stops it from reloading.