I renamed each of the coverage report files to .txt instead of .exec and 
ran the builds again. Same result, so its not down to the generated files 
having an executable like extension (.exec).

I'm working with our admin to try and get the virus scanner disabled next.


On Thursday, August 9, 2018 at 8:24:25 PM UTC+1, Richard Ashe wrote:
>
> Thanks Marc. I’ll try to disable the virus scanner and/or rename the files 
> to use a different extension other than .exec. If it is a virus scanner 
> then it may have a problem with the creation of files that look like .exe 
> files.
>
>
> On 9 Aug 2018, at 17:42, Marc Hoffmann <hoffm...@mountainminds.com> wrote:
>
> I talked to a colleage today about this issue. This seems to be the 
> typical behavour of virus scanners (or a virus ;).
>
> Can you try to run the test with the scanner disabled or uninstalled?
>
> Regards,
> -marc
>
> On 9. Aug 2018, at 18:29, Evgeny Mandrikov <mandri...@gmail.com> wrote:
>
> I just downloaded Windows 7 VM from 
> https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
> installed JDK 8u181, Maven 3.3.9
> and executed "mvn clean install" on the attached simple project
> what produced "target/jacoco.exec" - it has correct owner and can be 
> deleted:
>
> <win.png>
>
> No idea what else we can do.
>
> Questions that you ignored:
> Is it possible that some processes hold access to exec-file after 
> execution of Maven?
> Antivirus?
>
> Also according to searches in Google by words "owner can't delete windows 
> 7", also seriously doubt that problem is specific to or in JaCoCo.
>
>
> Regards,
> Evgeny
>
>
> On Thursday, August 9, 2018 at 9:32:20 AM UTC+2, Richard Ashe wrote:
>>
>> Hi,
>>
>> Its run on the command line using a mvn clean install command running 
>> with me as the user (local account) 
>>
>> All files created should have me as the owner, but the .exec files are 
>> locked down and I can't determine their owner, even if I switch to using an 
>> admin account. 
>>
>> After reboot I become the owner of the .exec files again.
>>
>> Thanks,
>> Richard.
>>
>> On Wednesday, August 8, 2018 at 4:41:55 PM UTC+1, Marc R. Hoffmann wrote:
>>>
>>> Hi,
>>>
>>> under what user do you run the process which the JaCoCo agent is 
>>> attached to? Is it maybe running as a windows service?
>>>
>>> Can you provide some more information about the permissions? Who is the 
>>> owner after creation? Who becomes the owner after reboot?
>>>
>>> Some Google hits suggest that this behaviour can be caused by virus 
>>> scanners.
>>>
>>> Regards,
>>> -marc
>>>
>>>
>>> On 8. Aug 2018, at 16:46, Richard Ashe <ashe.r...@gmail.com> wrote:
>>>
>>> Hi Evgeny,
>>>
>>> On Wednesday, August 8, 2018 at 1:14:37 PM UTC+1, Evgeny Mandrikov wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Wednesday, August 8, 2018 at 1:17:56 PM UTC+2, Richard Ashe wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Seeing an issue when I'm running jacoco tests through maven.
>>>>>
>>>>> I run a build, which generates coverage reports  - .exec files
>>>>>
>>>>> When I run mvn clean it fails as it can't delete the generated .exec 
>>>>> files. When I look at the .exec file, I can see the owner of the .exec 
>>>>> has 
>>>>> changed and I don't have access to delete the file anymore.
>>>>>
>>>>
>>>> JaCoCo has no code that explicitly manipulates with owner of 
>>>> created/updated files.
>>>>  
>>>>
>>>>> If I reboot my pc, the .exec file is now accessible again and I can 
>>>>> delete it.
>>>>>
>>>>
>>>> It is strange that reboot affects owner of a file - I'm wondering 
>>>> whether term "owner" is used correctly or you mean something else?
>>>>
>>>
>>> No - if I try to view the .exec file permissions and owner, I get an 
>>> error message saying that only the owner of the file can view these 
>>> details. Even if I use an admin account, I still can't delete the file as I 
>>> am no longer the owner. After a reboot, I can delete and access as normal 
>>> and owner has reverted to me.
>>>
>>>>
>>>> The only thing that JaCoCo agent does - is a standard Java-way of 
>>>> locking file using 
>>>> https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#lock()
>>>>   to prevent concurrent writes to the same file from different 
>>>> processes.
>>>> Corresponding code ( 
>>>> https://github.com/jacoco/jacoco/blob/v0.8.1/org.jacoco.agent.rt/src/org/jacoco/agent/rt/internal/output/FileOutput.java#L68-L69
>>>>  ) 
>>>> is there for about 6 years - https://github.com/jacoco/jacoco/pull/52
>>>> and so far we are not aware of any problems with this.
>>>> Is it possible that your build does not terminate all started JVMs? or 
>>>> does not terminate them gracefully?
>>>>
>>>>  
>>>>
>>>>> Same issue was reported here:
>>>>> https://issues.jenkins-ci.org/browse/JENKINS-28636 
>>>>> <https://www.google.com/url?q=https%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-28636&sa=D&sntz=1&usg=AFQjCNF8R0f7_20FcFz0sX6tmYsoswNAOw>
>>>>>
>>>>
>>>> Why it is the same? "owner" is not mentioned at all.
>>>>
>>> Its the same result. Jenkins is doing the same thing as maven - i.e. 
>>> running jacoco and the same file is getting locked down.
>>>  
>>>
>>>> Similarly to the resolution status "Cannot Reproduce" of this 
>>>> Jenkins-ticket - how to reproduce this? Which operating system you use? 
>>>> Which file system? Which JVM? Example of build?
>>>>
>>> Its reproducible using maven 3.3.9 on a windows 7 PC. Run a maven clean 
>>> install which calls jacoco which generates jacoco-ut.exe files. When the 
>>> build completes, run it again. This time, the clean fails as mvn can;t 
>>> delete the jacoco-ut.exec file as its locked down. Reboot, run again and 
>>> this time it works fine. Run the build again and it locks down again.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "JaCoCo and EclEmma Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jacoco+un...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jacoco/31b43c5a-80ae-4467-a03d-e5d96e02c521%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jacoco/31b43c5a-80ae-4467-a03d-e5d96e02c521%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> -- 
> You received this message because you are subscribed to the Google Groups 
> "JaCoCo and EclEmma Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jacoco+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jacoco/5eff5441-7b16-4679-b82b-e0bb26df515e%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jacoco/5eff5441-7b16-4679-b82b-e0bb26df515e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
> <example.zip>
>
> <win.png>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "JaCoCo and EclEmma Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jacoco+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jacoco/B2280EFB-B749-47B1-9FF5-08111AD9F73E%40mountainminds.com
>  
> <https://groups.google.com/d/msgid/jacoco/B2280EFB-B749-47B1-9FF5-08111AD9F73E%40mountainminds.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jacoco+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jacoco/3dea67d9-7061-408a-9839-7ccd5315da3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to