Unfortunately that's not practical due to the setup I have to work with.
Actually that's the easiest thing of the world. I work with it like that every day, it's a snap to set up, and the program does not even know it is not working on a real drive. Really, you should try that.
But I think it's important that the developers here see that this problem exists, which might actually be easy to fix.
The real problem is that the naming scheme
\\server\some\dir is incompatible with everything in the world except Windows Explorer. It will be rather hard if not impossible to fix this.
In fact, this stupid Microsoft scheme is what prevents the application from using forward-slashes for all file locations, which would be a lot more compatible, more efficient, a lot easier to implement, and a lot less error prone. Many (if not all) of our filesystem related problems only arise because the Windows designers are too ignorant, too stupid or too lazy to support forward slashes in network folders (or any other scheme which is in any way compatible to anything, for that matter).
It is because of this that every path gets converted to and from different representations and re-normalized all the time, which consumes the major part of your CPU time.
Just to give you a figure about how expensive this really is: While adding a file to a project, the path is mangled about a dozen times. A whole 35% of the total time needed to load a project goes into
wxFileName::Normalize alone (and another 30% into other pathname mangling).
<End of MS rant>