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

[Baesken, Matthias]

>  you should think of a JLI_open function and then you can
> put its implementation into the Windows version of java_md.c.

Hi Christoph, I like this idea .

New webrev :


http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/


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

Maybe I could put something into the existing

  jdk/test/jdk/tools/launcher

tests.   


Best regards, Matthias



> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 28. Januar 2019 14:23
> To: Baesken, Matthias <matthias.baesken at sap.com>; Alan Bateman
> <Alan.Bateman at oracle.com>; core-libs-dev at openjdk.java.net
> Subject: RE: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
> 
> 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
>