I've noticed that going through a junction does cause a speed hiccup- and it doesn't always refresh the directories.Hm, interesting - I can't OTOH think of a reason junctions should cause speed hiccups... they might involve an extra ACL lookup, and the need to read FS metadata for the destination could introduce a little disk seeking. But enough to cause a hiccup? Hmm!
And what with the "doesn't always refresh" - how does this manifest itself?
The speed hiccup manifests itself in the opening of file dialogs or the browsing to the directory. If I open a file dialog that defaults to a junction, or browse through a junction in a file dialog (or sometimes in explorer), there will be a short pause while the junction is opened. Once I'm in the junction, it's fine- but that first crossing of the junction can make it pause. It's a short pause, but it's there.
The doesn't always refresh- If I copy a file to the junction and have a window open to the directory, the file appears in the window I have open to the directory. In that same scenario, if I copy a file over through the regular directory, it doesn't appear in the junction until I explicitly refresh the directory. By 'always' I mean that I can't say with certainty that other programs don't see the copied file, but I've had some strange occurences, though it's not frequent enough to override the use of junctions.
I still wonder if the solution is to get the junction directory to recognize the change. Do you think that AHK could look at the file to see when the timestamp changes, then touch the file again through the junction?
I'm not sure what that means, to be honest.
As for your case Deozaan, I think that Dropbox uses file date/time stamps to see when to update a file (among other things), so that if you changed the file date/time stamp through the junction, Dropbox might pick it up. That's just a hypothesis, though. I think that AHK could do this fairly easy... I'm not well-versed in AHK yet, but if no-one speaks up, I can probably give it a go.