Dustmite + Visual D

Vladimir Panteleev thecybershadow.lists at gmail.com
Sun Nov 4 22:12:16 UTC 2018


On Sunday, 4 November 2018 at 21:11:27 UTC, Michelle Long wrote:
> No, have you not learned in your life time that just because 
> something or someeone says something doesn't make it true?

In all my years of using Windows, I have never seen or heard for 
this error message to lie (i.e. occur due to a reason different 
than what it states). I've also used junctions and symbolic links 
a lot.

It's possible the junction is confusing some software into not 
closing a file, though.

> Nope, none of this because I run none. Please trust people a 
> bit more when they say what they say. Not everyone is an 
> imbecile.

Sometimes, the reason can be really unobvious. We've ran into a 
similar problem a while ago on CI machines, which turned out to 
be the security software included with the then-new version of 
Windows. It doesn't hurt to check.

> This has nothing to do with dustmite as far as I know. That is 
> the full output.

Probably trying to invoke Dustmite manually would be progress 
then, with the Visual D bug report aside.

> If this is dustmite and not visual D then it most likely is due 
> to the junction.

1. DustMite will not touch anything outside the parent directory 
of the path you give it (though the test command might).
2. DustMite doesn't care about junctions and treats them as 
directories. When creating test copies of the source, it will 
recreate the directory structure with junctions replaced with 
directories.

> 1. There is little else it could be except visual studio itself 
> locking the file, which it doesn't seem to be and has worked 
> before.

FWIW, you can use Process Explorer (by Microsoft) or Process 
Hacker (FOSS) to find which processes hold handles to a file. 
That might provide a clue.

> 2. Junctions are known to cause problems with some copy 
> routines because one can't simply copy a junction as normal. 
> The reason being is the junction suppose to be duplicated or 
> all the data?

Yes, well known gotcha. std.file.dirEntries has a followSymlink 
parameter. DustMite uses the default (true).



More information about the Digitalmars-d-ide mailing list