Disk synchronization software and FTN95: interaction?!

A very long shot, this, but I'm stuck for a better explanation. I was going to post about it yesterday but the symptoms went away again. Now I've decided that doesn't mean it never happened, and I'd like to try and understand it. So I'm seeking opinions on the possibility that disk synchronization software could interfere with a compiler and/or debugger. Here's a summary of what I observed yesterday and now can not reproduce.

I was making some 'minor' (I know, I know ...) changes to a code that has worked perfectly for years: The first symptom of something seriously amiss came when I tried to run it in a different folder. The exe ran stand-alone, but SDBG access violated at address 0x0 when it tried to load the exe. No problem in the original folder.

The second symptom came when I actually ran the program, in the original location, and it decided that it couldn't divide by a variable because it was undefined. This variable is declared and calculated in the same routine. Running the program with SDBG showed that the variable was indeed being calculated, but becoming undefined by the time it was used later in the same routine. Running it again with a USE break on the same variable showed the same behaviour, but the only USEs in the routine were i) to calculate it and ii) to divide by it, by which time it was undefined. At this point I resorted to voodoo. I cold-rebooted and rearranged my code. At some point both problems vanished ...

Now that we have a 'managed desktop' environment at work, we have disk synchronization software called Vice Versa, whose function is to wake up whenever it detects changes in the files on the hard disk, and to mirror those changes to a network location. I am suspicious of this software because while all this bizarre stuff was going on, I noticed that trivial operations in windows Explorer - like 'select a file' - were consuming up to 15 seconds of eggtimer.

If you're still reading, thank you for your attention. I'd be very grateful for any opinions on what might have been going on here.

Andy

Chances are you will do this anyway but in situations like this I normally resort to a complete rebuild.

Oh, I was rebuilding like it was going out of fashion (sorry, I should have mentioned that) ... :lol: ... but the problems were persistent between rebuilds. That's why I last-resorted to a cold reboot.

If we go with the notion that Vice Versa was somehow responsible, I do wonder if rapid-fire rebuilding was part of the problem. Suppose a rebuild, that triggers a mirroring process, and that that process is not complete before another rebuild takes place, triggering another mirroring process, and possibly so on. Without knowing the dirty detail of how Vice Versa does what it does, it seems to me to be possible that the mirrored version of the project would contain a mixture of obj and mod files from the two rebuilds. This mixture would then be mirrored back (because the files in the two locations have to end up the same), and the next rebuild would be corrupt as a result.

Does this sound remotely plausible? In fact, I just had a look and Vice Versa has a forum just like this. I'll ask there!

Andy

There is an issue when you type something like this:

sdbg myprogram

If there are multiple copies of myprogram.exe it can pick up the wrong one. Needless to say this can cause problems 😄 The problem typically appears when I try and debug the compiler, I type

sdbg ftn95 /p z.f90 /debug

and it goes wonky because it has loaded the wrong ftn95.exe. sdbg tries to spot this but it is not 100% foolproof. If in doubt, use a full pathname.