RFR : 8217093: Support extended-length paths in parse_manifest.c on windows
Baesken, Matthias
matthias.baesken at sap.com
Wed Feb 6 09:20:33 UTC 2019
Thanks .
Looks like there are a few open calls in windows or shared code present , for example :
Zlib:
gzlib.c
hotspot:
osSupport_windows.cpp
compactHashtable.cpp
but mostly it is CreateFile(W) ( not sure if it is always with extended length path support).
We could also compare what is done in JDK and in Windows HS os::open
int os::open(const char *path, int oflag, int mode) {
from os_windows.cpp (this creates an UNC path + uses _wopen ).
Best regards, Matthias
> -----Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 6. Februar 2019 10:08
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: core-libs-dev at openjdk.java.net; Alan Bateman
> <Alan.Bateman at oracle.com>
> Subject: RE: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
>
> Hi Matthias,
>
> thanks for opening the bug. I refined its description a little...
>
> Best regards
> Christoph
>
> > -----Original Message-----
> > From: Alan Bateman <Alan.Bateman at oracle.com>
> > Sent: Mittwoch, 6. Februar 2019 10:00
> > To: Langer, Christoph <christoph.langer at sap.com>; Baesken, Matthias
> > <matthias.baesken at sap.com>
> > Cc: core-libs-dev at openjdk.java.net
> > Subject: Re: RFR : 8217093: Support extended-length paths in
> > parse_manifest.c on windows
> >
> >
> > On 29/01/2019 08:58, Langer, Christoph wrote:
> > > Hi Matthias,
> > >
> > >>> New webrev :
> > >>>
> > >>>
> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/
> > >> This is the one. Looks good ( and clean ).
> > > I agree, this version would be ok for me to be pushed. It would be good
> > ,though, if there was a test for this (long paths on Windows).
> > >
> > > I also like Alan's suggestion to open a follow up bug to explore using
> > CreateFile on Windows right away rather than trying open. Looking at
> > libjava/libnet/libnio, it's all CreateFileW on Windows...
> > I think the right fix is to convert a relative path into absolute path,
> > apply the prefix for long paths, and then use CreateFileW consistently.
> > It's probably okay to get there in steps but I can't tell from the
> > current webrev if it works with relative paths or not.
> >
> > -Alan
More information about the core-libs-dev
mailing list