> Did you consider adding a Unix version of open_jarfile to avoid #ifdef > WIN32 ?
Hi Alan, do you mean , adding a separate c-file for UNIX containing the function open_jarfile ? I considered this, but did not like the idea to add a separate file for UNIX just for the small function . Your suggestion to use FILE_SHARE_READ is probably the right way to do it , I changed this, second webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.2/ Best Regards, Matthias > -----Original Message----- > From: Alan Bateman <[email protected]> > Sent: Donnerstag, 24. Januar 2019 13:04 > To: Baesken, Matthias <[email protected]>; core-libs- > [email protected] > Subject: Re: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > On 23/01/2019 08:29, Baesken, Matthias wrote: > > Hello Alan, here is a second webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.1/ > > > > I moved the Windows-only code into a new file > > > > src/java.base/windows/native/libjli/parse_manifest_md.c > > > Did you consider adding a Unix version of open_jarfile to avoid #ifdef > WIN32 ? > > On the Windows version then your patch is low risk but the retrying > after ENOENT is a bit icky. I'm just wondering if you've considered > creating an absolute path and adding the prefix when the length is 247 > or greater. I also wonder about the share mode specified to CreateFileW > where it might be better to specify FILE_SHARE_READ at least so that you > don't exclude other processes from also opening the file to read. > > -Alan
