Dustmite + Visual D

[Rainer Schuetze]

On 08/11/2018 10:43, Michelle Long wrote:
> On Thursday, 8 November 2018 at 07:16:19 UTC, Rainer Schuetze wrote:
>>
>>
>> On 06/11/2018 04:09, Michelle Long wrote:
>>> D:\Projects\Game\Game\Game.dustmite\..\..\..\..\D\Libraries\pegged\dynamic\grammar.d:
>>>
>>> The process cannot access the file because it is being used by another
>>> process.
>>>
>>
>> I can reproduce it now, but it has nothing to do with links/junctions.
>>
>> The problem is that the shown file is outside of the project folder
>> hierarchy. Visual D tries to recreate the projects folder structure,
>> so it copies
>>
>> D:\Projects\Game\Game\Game\..\..\..\..\D\Libraries\pegged\dynamic\grammar.d
>>
>>
>> to
>>
>> D:\Projects\Game\Game\Game.dustmite\..\..\..\..\D\Libraries\pegged\dynamic\grammar.d
>>
>>
>> which is the same file!
>>
>> A simple workaround is to use a junction in the project folder to
>> access pegged.
>>
>> I guess Visual D should not copy files outside of the project folder,
>> but they are also not subject to dustmite in that case.
>>
>> Alternatively, the dustmite directory could be created in a common
>> parent folder for all files, but that doesn't work for files
>> distributed over different drives.
> 
> whoo! ;) That dogged a bullet! Glad you were able to figure it out.
> 
> I am using a junction!
> 
> I have my libs in D\Libraries.
> 
> In my project I have a junction that points to it.
> 
> I dragged that junction to VS to add the files.
> 
> So they don't exist at the same place.
> 
> Visual D seems to copy some of the files.
> 
> Maybe the better solution would just be to delay and repeat.
> 
> If somehow it is copying two files simultaneously then the delay and
> retry might a few times will just copy it twice(it would have to
> override it).
> 
> Or maybe just check if the file already exists and avoid copying it?
> (although the grammar.d file that it complained about was never copied,
> so this probably won't work)
> 
> Maybe you could simply record any failures and try them at the end.
> 
> Here I'm assuming the locking is temporary and will disappear quickly
> enough given that I can never see the file being locked.
> 
> 

I suspect there is still a misunderstanding: your project very likely
still refers to these files via a relative path, not through the
junction. You can verify this by looking at the list of files at the end
of the .visualdproj file with a text editor.