Dustmite + Visual D

[Michelle Long]

On Sunday, 4 November 2018 at 22:12:16 UTC, Vladimir Panteleev 
wrote:
> 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).


I am pretty sure it is a bug in Visual D not handling the 
junction right. It was a fresh boot with no other programs ran 
before and given other experiences it seems almost surely(95%+) 
that it is a junction problem with visual D. Since it is such a 
high liklihood it should be the first thing tried.

While I could run dustmite from the command line, the point of 
using visual D is because it handles it all automatically, which 
is nice, when it works.

Now, I can't be sure if it's Visual D or Dustmite because that is 
the only error I get, but visual D says it needs to copy the 
project to a temp folder and then the error appears immediately. 
I bet if I replaced the junction with a normal directory it would 
work but then that defeats the purpose of using a junction.

It would take Rainer just a few minutes max to determine this by 
simply created a project or opening a pre-existing one and adding 
a junction the dragging it to the project and adding a d file in 
it then trying the dustmite command.

Again, I do not think this is a dustmite problem, it occurs when 
trying to run dustmite using the Visual D dustmite command(which, 
again, has worked in the past without issue and all it does is 
copy the project then run dustmite... and the error is about 
accessing a file).

Because I'm sure this is related to Visual D and 
junctions(whatever copying method it uses) I'm willing not to try 
random stuff to try and fix it... expecting that Rainer can 
reproduce this problem fairly quickly when he gets time. If he 
adds a junction and it doesn't have an error then I will look in 
to it more on my side. No reason for me to spend hours trying to 
figure out possible edge cases until I know it is not the most 
probable cause. It will take him a few minutes to investigate and 
chances are it will be easily solved.

If it turns out something is locking the file, then that is still 
a problem because nothing I have done locks the file it complains 
on(so it's still a bug). I did not ever touch that file in any 
way. I simply loaded the project and ran the command(the file is 
not even loaded in the editor or being accessed by anything 
external(unless windows is doing funky shit, which I doubt since 
I disabled most of all the crap it does)).