Re: [java code coverage] Re: Can't delete .exec coverage report files

2018-08-09 Thread Richard Ashe 
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  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  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:
>> 
>> 
>> 
>> 
>> 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  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
>>> 
>> 
>> 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

Re: [java code coverage] Re: Can't delete .exec coverage report files

2018-08-09 Thread Evgeny Mandrikov 
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:

[image: 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  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 
 

>>>
>>> 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
>>  
>>

Re: [java code coverage] Re: Can't delete .exec coverage report files

2018-08-09 Thread Richard Ashe 
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 > 
> 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 
>>> 
>>>
>>
>> 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
>  
> 
> .
> 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/4e9a846d-1f40-471a-b019-9f94dde0eeb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [java code coverage] Re: Can't delete .exec coverage report files

2018-08-08 Thread Marc Hoffmann 
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  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 
> 
> 
> 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+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jacoco/31b43c5a-80ae-4467-a03d-e5d96e02c521%40googlegroups.com
>  
> .
> 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/CEE6B1BA-27B1-47C3-A191-A7B31352C5C9%40mountainminds.com.
For more options, visit https://groups.google.com/d/optout.