RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

[Baesken, Matthias]

> 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 <Alan.Bateman at oracle.com>
> Sent: Donnerstag, 24. Januar 2019 13:04
> To: Baesken, Matthias <matthias.baesken at sap.com>; core-libs-
> dev at openjdk.java.net
> 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