Am Donnerstag, 7. Februar 2013, 08:45:57 schrieb Till Oliver Knoll: > Am 07.02.2013 um 02:59 schrieb Scott Aron Bloom <scott.bl...@onshorecs.com>: > > Just a suggestion... > > > > If you use a "Project" directory, for source and building, add that > > directory to your virus system as a white listed directory, ie don't > > check it. > Guido already stated that he's not using any virus scanner ;)
Yes, but it's in general a good advice to not let virus scanners interfer with your "work" - including all consequences of that: Don't extract anything obtained form internet into your source directories - at least not directly. However, I know at least of 2 virus scanners who sometimes accidently conclude that some temporary file generated during the compilation of Qt using Visual Studio is a virus. Resulting in removal of the file and build process stopping, which is a similar problem as with the resource file update-thing. > My second guess would have been "network drive" (Samba, network delay, > wrong/cached permissions, other oddities...) but he mentioned the C:\ > drive, so I assume that means local... Indeed, unlikely on C:\ > Is the entire compilation process "multithreaded"? Could it be that some VS > 2010 process is trying to access that DLL at the same time like some other > VS process (which might then be a bug in VS itself, maybe triggered by > "unusual generated Makefiles")? Is it possible to force "single process > compilation/linking" in this case? The whole nmake-process (which he said he's using) is not threaded at all. That's in fact why jom exists. > What Windows version was that again? Is it possible that some "search index" > is being updated at the very moment that DLL is to be generated? Possibile - but i've personally never seen that before. Another piece of software that might be interested in a just-now-built executable might be VS's pdb-server, which is a background server process for accessing debug-symbols that is fed in background during compilation and used during debugging sessions. > What about trying to compile Qt onto some externally attached drive? Maybe > your hard disk really has bad blocks which are just being marked as such > the very moment you try to write them (any other data lost or corrupted > recently? :-0)? (Doesn't that S.M.A.R.T. thing do that? Or was that just > with "USB sticks"?) Yes, it's the S.M.A.R.T. thing that does this - and it can be easily looked up with a smart-monitoring tool. Bad-Sector relocation also applies to "conventional" magnetic hard discs (They also have some fail over capacity). OTOH nowadays, it is more likely that such happens on flash drives like USB sticks, SD-Cards and SSD-type hard disc drives. Actually, I've seen a few SSDs die, but this process usually shows "more serious" behaviour. > And finally: did you try to tilt and maybe slightly shake your harddisk, > such that the bits fall into the right place again? Isn't this recommended against bit-rotting only? > Maybe you have to adjust its orientation towards Redmond, too (No > responsibility taken ;)) Unless you share the distance to equator with Redmond, in which case earth- magnetism may interfere with such alignment :-) > > [From: "The Developer's Handbook About Esotheric Bugs You Wouldn't Believe > They Exist (And Some Really Don't)" - Buggy Bookstore Press, ISBN 42] Sascha _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
