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

[Langer, Christoph]

Hi Matthias,

thanks for the update.

I still think you should avoid introducing a file parse_manifest_md.c. As per my previous mail, you should think of a JLI_open function and then you can put its implementation into the Windows version of java_md.c. You can take example on the implementation of JLI_Snprintf which has coding on Windows and for Unix it's just a #define to snprintf.

Would it be possible to add a jtreg testcase that shows/tests the issue?

Best regards
Christoph

> -----Original Message-----
> From: Baesken, Matthias
> Sent: Montag, 28. Januar 2019 12:38
> To: Alan Bateman <Alan.Bateman at oracle.com>; core-libs-
> dev at openjdk.java.net
> Cc: Langer, Christoph <christoph.langer at sap.com>
> Subject: RE: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
> 
> Hello Alan / Christoph,
> new webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.3/
> 
> - moved ELP_PREFIX define out of the function
> - added a check    (wfullnamelen > 247)   before CreateFileW  is attempted
> - some other formatting (mostly suggested by Christoph)
> 
> 
> Best regards, Matthias
> 
> 
> > -----Original Message-----
> > From: Alan Bateman <Alan.Bateman at oracle.com>
> > Sent: Sonntag, 27. Januar 2019 16:57
> > To: Baesken, Matthias <matthias.baesken at sap.com>; core-libs-
> > dev at openjdk.java.net
> > Cc: Langer, Christoph <christoph.langer at sap.com>
> > Subject: Re: RFR : 8217093: Support extended-length paths in
> > parse_manifest.c on windows
> >
> > On 24/01/2019 16:19, Baesken, Matthias wrote:
> > >> 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/
> > >
> > Christoph Langer's suggestion to use jli_util seems worth exploring to
> > keep the platform specific code together.
> >
> > I still find the call to _open and checking for ENOENT a bit icky. If
> > this change gets pushed then I think we need a follow-up issue created
> > to replace this to use CreateFile consistently.
> >
> > -Alan