Hi, I agree with Evgeny here. We introduced file locking because we had many reports with broken exec files from concurrent access. I really don’t want to debug these issues again.
So for me this is a acceptable limitation. We can e.g. add it to the FAQ. Regards, -marc > On 7. Oct 2019, at 19:45, Evgeny Mandrikov <[email protected]> wrote: > > Hi, > > > On Friday, October 4, 2019 at 8:13:25 PM UTC+2, [email protected] > <mailto:[email protected]> wrote: > I tried submitting a bug report to https://github.com/jacoco/jacoco > <https://github.com/jacoco/jacoco> but I get the following message "An owner > of this repository has limited the ability to open an issue from new users." > so I will try here. If there is a better place to submit this bug let me know. > > > Yes - we restrict interactions with GitHub repository for new accounts, > because otherwise instead of sending questions to mailing list, many people > use our bug tracker. > > So thank you for message here. > > > > Bug / RFE > > When running jacoco on an SMB file share I get the following message: > > java.io.IOException: Operation not supported > > at sun.nio.ch.FileDispatcherImpl.lock0(Native Method) > > at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:94) > > > at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1078) > > > at java.nio.channels.FileChannel.lock(FileChannel.java:1053) > > > at > org.jacoco.agent.rt.internal_035b120.output.FileOutput.openFile(FileOutput.java:69) > > ... > > > > This seems to be cause by defect JDK-8167023 > <https://www.google.com/url?q=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8167023&sa=D&sntz=1&usg=AFQjCNGS77ki-JlfyaHfLxEIPLCtrlms4A> > (lock not supported) and likely fails for most network shares using AFP / > SMB from macOS. Note the JDK issue has been open over 3 years now and is > unlikely to be fixed anytime soon. > > I would like to suggest foregoing the lock when an IOException is detected > instead of failing completely. Below is the code that is failing (yellow) > with suggested changes (green). > > public class FileOutput implements IAgentOutput { > > ... > > private OutputStream openFile() throws IOException { > final FileOutputStream file = new FileOutputStream(destFile, > append); > // Avoid concurrent writes from different agents running in > parallel: > try { > file.getChannel().lock(); > } catch(IOException e) {/* Proceed without lock */} > return file; > } > > ... > > } > > > > However I seriously doubt that we can sacrifice correctness of concurrent > access to file on support of network disks. > And ignoring of exceptions is not what we prefer, because this complicates > diagnosis of problems for users and for us in case of questions from users. > So IMO the best what we can do - is to document this limitation and advise > you to not place file on a network device. > > Marc, WDYT? > > > > Regards, > Evgeny > > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jacoco/2940e5b6-bf10-4e58-9a68-79d066e74d43%40googlegroups.com > > <https://groups.google.com/d/msgid/jacoco/2940e5b6-bf10-4e58-9a68-79d066e74d43%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/9F57E296-76FF-4D76-9CFB-7DA722BB5962%40mountainminds.com.
