From Alan.Bateman at oracle.com Mon Dec 1 08:42:25 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 01 Dec 2014 08:42:25 +0000 Subject: Better NewIO2 file system implementation for AIX platform In-Reply-To: References: Message-ID: <547C29F1.6040303@oracle.com> On 01/12/2014 08:06, deven you wrote: > Hi All, > > Our current NIO2 file system support to AIX is very limited, hence I took > some time to try to complete it. Openjdk bug[1] tracks this bug and here is > my patch[2] which enhances the AIX file system especially by adding the > support by Implementing AixDosFileAttributeView.java and > AixUserDefinedFileAttributeView.java. > > Could anyone take a look? > Does SAMBA or other CIFS servers running on AIX store the DOS attributes as extended attributes? I'm just wondering if the DOS file attribute view makes sense or not. I suspect you will need to update a number of tests to (like FileSystem/Basic.java) and Files/CopyAndMove.java) to ensure that this new code is exercised by the tests. A minor comment but we usually use 4-space indentation in the library native code. -Alan From Alan.Bateman at oracle.com Mon Dec 1 08:52:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 01 Dec 2014 08:52:31 +0000 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: References: <547ADE20.2060102@oracle.com> <547B4920.2010105@oracle.com> <547B818F.2060600@oracle.com> Message-ID: <547C2C4F.5080705@oracle.com> On 30/11/2014 21:47, Francis Galiegue wrote: > : > OK, that makes sense -- however I didn't know that the first path was > valid at all; or even whether it can represent anything at all... It just provides access to file "foo" in the working directory of drive "C:". > : > Well, if you cannot convert from/to the necessary byte array, you are > supposed to throw an InvalidPathException, correct? In UnixPath I see > that a Charset{De,En}coder is used for these purposes with a > CodingErrorAction of REPORT. As it's all the one file system provider then you shouldn't need to do any encoding or decoding. > : > > > And there's even a contradiction there: what is "the empty path"? An > empty path attached to the file system of "path" or "other"? On Linux, > it returns "other" unconditionally, which says it's the first part > which takes precedence. > > So, should this last part of the documentation be removed? > The empty path is defined is in the class description. I don't see any obvious with the resolveSibling's javadoc, it' just trying to be explicit as to how it behaves when the the path or given path is the empty path. -Alan From daniel.fuchs at oracle.com Mon Dec 1 09:15:14 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 01 Dec 2014 10:15:14 +0100 Subject: Typo in javadoc of Path's .normalize()? In-Reply-To: <5479E3A8.1080409@oracle.com> References: <5479E1AB.3060602@oracle.com> <5479E3A8.1080409@oracle.com> Message-ID: <547C31A2.1060804@oracle.com> Hi Alan, Looks good to me. -- daniel On 29/11/14 16:18, Alan Bateman wrote: > I've created JDK-8066196 to track, the diff is trivial and will push to > JDK 9 once I get a Reviewer. > > -Alan. > > diff --git a/src/java.base/share/classes/java/nio/file/Path.java > b/src/java.base/share/classes/java/nio/file/Path.java > --- a/src/java.base/share/classes/java/nio/file/Path.java > +++ b/src/java.base/share/classes/java/nio/file/Path.java > @@ -325,7 +325,7 @@ > * > * @return the resulting path or this path if it does not contain > * redundant name elements; an empty path is returned if > this path > - * does have a root component and all name elements are > redundant > + * does not have a root component and all name elements > are redundant > * > * @see #getParent > * @see #toRealPath From volker.simonis at gmail.com Mon Dec 1 18:38:44 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 1 Dec 2014 19:38:44 +0100 Subject: Better NewIO2 file system implementation for AIX platform In-Reply-To: <547C29F1.6040303@oracle.com> References: <547C29F1.6040303@oracle.com> Message-ID: On Mon, Dec 1, 2014 at 9:42 AM, Alan Bateman wrote: > On 01/12/2014 08:06, deven you wrote: >> >> Hi All, >> Hi Deven, thank you for your contribution. Please find my comments inline: >> Our current NIO2 file system support to AIX is very limited, hence I took >> some time to try to complete it. Openjdk bug[1] tracks this bug and here >> is >> my patch[2] which enhances the AIX file system especially by adding the >> support by Implementing AixDosFileAttributeView.java and >> AixUserDefinedFileAttributeView.java. >>. >> Could anyone take a look? >> > Does SAMBA or other CIFS servers running on AIX store the DOS attributes as > extended attributes? I'm just wondering if the DOS file attribute view makes > sense or not. > I'm by no means an expert in this area and just started to experiment a little bit. While looking at tests like 'java/nio/file/attribute/DosFileAttributeView/Basic.java' I was surprised to see that DosFileAttributeView can also be used on Linux. While this makes sense for DOS file systems mounted into Linux which map the DOS attributes to extended attributes on Unix it is probably academic for file systems like ext2/3/4 which support extended attributes as well. Unfortunately, tests like DosFileAttributeView/Basic.java mostly test extended attributes on a Linux files system because they only create and change files in /tmp which is hardly ever a mounted DOS file system. All that said, on AIX the JFS2 file system also supports extended attributes (see http://en.wikipedia.org/wiki/Extended_file_attributes). Hopefully the CIFS client correctly maps the DOS attributes to extended user attributes but I couldn't check that today because I couldn't find a AIX box with CIFS client today. I'll try to find one tomorrow, but perhaps Deven can already confirm this? Following some more comments: AixDosFileAttributeView.java - please replace "ext3" by "JFS2" in the comment as I'm not aware of any ext3 support in AIX AixFileStore.java - the detection if extended attributes are supported doesn't seem to work. It seems like supportsFileAttributeView() has been just copied from the corresponding Linux implementation but that won't work on AIX. Please remove the ext3/4 stuff and do a real check (i.e. check if the file system is JFS2 and if extended attributes have been enabled on on the corresponding file system. See 'chfs -a ea=v2', 'man 2 getea', setea, ...). - the test DosFileAttributeView/Basic.java should succeed without saying "DOS file attribute not supported." AixNativeDispatcher.java AixNativeDispatcher.c - you define 'getAixMountEntries()', 'queryMountEntrySize()' and the corresponding native implementations but they don't seemed to be used anywhere. Please remove this dead code. If you need to get a list of all mounted file systems you could use 'getmntctl()' which is already there and does exactly that. > I suspect you will need to update a number of tests to (like > FileSystem/Basic.java) and Files/CopyAndMove.java) to ensure that this new > code is exercised by the tests. > Yes, could you please elaborate how you have tested your implementation until now? Thank you and best regards, Volker > A minor comment but we usually use 4-space indentation in the library native > code. > > -Alan From fgaliegue at gmail.com Mon Dec 1 19:13:45 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 1 Dec 2014 20:13:45 +0100 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: <547C2C4F.5080705@oracle.com> References: <547ADE20.2060102@oracle.com> <547B4920.2010105@oracle.com> <547B818F.2060600@oracle.com> <547C2C4F.5080705@oracle.com> Message-ID: On Mon, Dec 1, 2014 at 9:52 AM, Alan Bateman wrote: > On 30/11/2014 21:47, Francis Galiegue wrote: >> >> : >> OK, that makes sense -- however I didn't know that the first path was >> valid at all; or even whether it can represent anything at all... > > It just provides access to file "foo" in the working directory of drive > "C:". > OK, thanks for the information... > > >> : >> Well, if you cannot convert from/to the necessary byte array, you are >> supposed to throw an InvalidPathException, correct? In UnixPath I see >> that a Charset{De,En}coder is used for these purposes with a >> CodingErrorAction of REPORT. > > As it's all the one file system provider then you shouldn't need to do any > encoding or decoding. > I was talking about _different_ providers here. Which makes me wonder, while we are at it, why the code for decoding/encoding path names is in UnixPath at all... (side note: short of changing the system encoding, you cannot alter the behaviour of this {de,en}coding process) >> >> And there's even a contradiction there: what is "the empty path"? An >> empty path attached to the file system of "path" or "other"? On Linux, >> it returns "other" unconditionally, which says it's the first part >> which takes precedence. >> >> So, should this last part of the documentation be removed? >> > The empty path is defined is in the class description. I don't see any > obvious with the resolveSibling's javadoc, it' just trying to be explicit as > to how it behaves when the the path or given path is the empty path. > As I said: an empty path _for which filesystem_? The one associated with the path you try to .resolveSibling() against or the one of the path given as an argument? This is what the documentation is not clear about (without even going to the provider level). -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From fgaliegue at gmail.com Mon Dec 1 22:19:02 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 1 Dec 2014 23:19:02 +0100 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: References: <547ADE20.2060102@oracle.com> <547B4920.2010105@oracle.com> <547B818F.2060600@oracle.com> <547C2C4F.5080705@oracle.com> Message-ID: On Mon, Dec 1, 2014 at 8:13 PM, Francis Galiegue wrote: > On Mon, Dec 1, 2014 at 9:52 AM, Alan Bateman wrote: [...] > > As I said: an empty path _for which filesystem_? The one associated > with the path you try to .resolveSibling() against or the one of the > path given as an argument? This is what the documentation is not clear > about (without even going to the provider level). > And as we are talking about "which filesystem" problems... Here is a good one: http://stackoverflow.com/q/27238404/1093528 -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From brian.burkhalter at oracle.com Tue Dec 2 01:07:41 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 1 Dec 2014 17:07:41 -0800 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: <5476DE75.6010909@oracle.com> References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> Message-ID: On Nov 27, 2014, at 12:19 AM, Alan Bateman wrote: > On 27/11/2014 00:35, Brian Burkhalter wrote: >> Please review at your convenience: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8025619 >> Patch: http://cr.openjdk.java.net/~bpb/8025619/webrev.00/ >> >> This patch fixes the immediate problem encountered by the test included in the issue description. The fix is simply for FileKey.create() to throw an IOException directly instead of wrapping it in an Error. >> >> This raises the question of whether some additional verbiage in the description of getChannel() might be necessary to remind that calling close() on the source object will render the FileChannel inviable and possibly cause unforeseen subsequent exceptions. >> >> Also, as noted in the issue comments, it begs the question as to whether getChannel() in FileInputStream, FileOutputStream, RendomAccessFile, etc., should return null or throw an IOException if the object on which it is invoked has already been closed. If so this would need to be addressed by an issue yet to be filed and would imply a documentation change. >> >> > I don't think the fix is right, consider for example what would happen if the file descriptor is recycled to another file before tryLock is called. Perhaps we are at cross-purposes here. The supplied patch was intended to address only the specific failure exposed by the test in the issue description. The last two paragraphs of the review request were in effect asking whether this issue should be constrained to this specific test error and a second issue filed for the more general case, or whether this issue should be used to cover both. Brian > One way to fix this would be to create the FileChannel in getChannel immediately close it (so that FileChannel doesn't leak out in the open state). This will need a bit of work in implCloseChannel, one idea is to have it be a no-op if !fs.valid(). -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Dec 2 08:39:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Dec 2014 09:39:13 +0100 Subject: Better NewIO2 file system implementation for AIX platform In-Reply-To: References: <547C29F1.6040303@oracle.com> Message-ID: Hi Deven, I've just realized that you still use the Linux functions fgetxattr, fsetxattr, ... I don't think this will ever work on AIX. Please use the corresponding functions from (i.e. getea, setea, removeea). Thanks, Volker On Mon, Dec 1, 2014 at 7:38 PM, Volker Simonis wrote: > On Mon, Dec 1, 2014 at 9:42 AM, Alan Bateman wrote: >> On 01/12/2014 08:06, deven you wrote: >>> >>> Hi All, >>> > > Hi Deven, > > thank you for your contribution. Please find my comments inline: > >>> Our current NIO2 file system support to AIX is very limited, hence I took >>> some time to try to complete it. Openjdk bug[1] tracks this bug and here >>> is >>> my patch[2] which enhances the AIX file system especially by adding the >>> support by Implementing AixDosFileAttributeView.java and >>> AixUserDefinedFileAttributeView.java. >>>. >>> Could anyone take a look? >>> >> Does SAMBA or other CIFS servers running on AIX store the DOS attributes as >> extended attributes? I'm just wondering if the DOS file attribute view makes >> sense or not. >> > > I'm by no means an expert in this area and just started to experiment > a little bit. While looking at tests like > 'java/nio/file/attribute/DosFileAttributeView/Basic.java' I was > surprised to see that DosFileAttributeView can also be used on Linux. > While this makes sense for DOS file systems mounted into Linux which > map the DOS attributes to extended attributes on Unix it is probably > academic for file systems like ext2/3/4 which support extended > attributes as well. Unfortunately, tests like > DosFileAttributeView/Basic.java mostly test extended attributes on a > Linux files system because they only create and change files in /tmp > which is hardly ever a mounted DOS file system. > > All that said, on AIX the JFS2 file system also supports extended > attributes (see > http://en.wikipedia.org/wiki/Extended_file_attributes). Hopefully the > CIFS client correctly maps the DOS attributes to extended user > attributes but I couldn't check that today because I couldn't find a > AIX box with CIFS client today. I'll try to find one tomorrow, but > perhaps Deven can already confirm this? > > Following some more comments: > > AixDosFileAttributeView.java > - please replace "ext3" by "JFS2" in the comment as I'm not aware of > any ext3 support in AIX > > AixFileStore.java > - the detection if extended attributes are supported doesn't seem to > work. It seems like supportsFileAttributeView() has been just copied > from the corresponding Linux implementation but that won't work on > AIX. Please remove the ext3/4 stuff and do a real check (i.e. check if > the file system is JFS2 and if extended attributes have been enabled > on on the corresponding file system. See 'chfs -a ea=v2', 'man 2 > getea', setea, ...). > - the test DosFileAttributeView/Basic.java should succeed without > saying "DOS file attribute not supported." > > AixNativeDispatcher.java > AixNativeDispatcher.c > - you define 'getAixMountEntries()', 'queryMountEntrySize()' and the > corresponding native implementations but they don't seemed to be used > anywhere. Please remove this dead code. If you need to get a list of > all mounted file systems you could use 'getmntctl()' which is already > there and does exactly that. > >> I suspect you will need to update a number of tests to (like >> FileSystem/Basic.java) and Files/CopyAndMove.java) to ensure that this new >> code is exercised by the tests. >> > > Yes, could you please elaborate how you have tested your > implementation until now? > > Thank you and best regards, > Volker > >> A minor comment but we usually use 4-space indentation in the library native >> code. >> >> -Alan From Alan.Bateman at oracle.com Tue Dec 2 08:59:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Dec 2014 08:59:41 +0000 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> Message-ID: <547D7F7D.5010505@oracle.com> On 02/12/2014 01:07, Brian Burkhalter wrote: > : > > Perhaps we are at cross-purposes here. The supplied patch was intended > to address only the specific failure exposed by the test in the issue > description. The last two paragraphs of the review request were in > effect asking whether this issue should be constrained to this > specific test error and a second issue filed for the more general > case, or whether this issue should be used to cover both. > I think it would be better to fix the underlying issue, which is that FIS/FOS/RAF will create a FileChannel that is open after the file has been closed. Try the patch below as a starting point. This will create the FileChannel and close it before the reference is handed out. A cleaner solution would be to create the FileChannel in the closed state but it would involve more intrusive changes. -Alan diff --git a/src/java.base/share/classes/java/io/FileInputStream.java b/src/java.base/share/classes/java/io/FileInputStream.java --- a/src/java.base/share/classes/java/io/FileInputStream.java +++ b/src/java.base/share/classes/java/io/FileInputStream.java @@ -367,6 +367,13 @@ synchronized (this) { if (channel == null) { channel = FileChannelImpl.open(fd, path, true, false, this); + if (closed) { + try { + channel.close(); + } catch (IOException ioe) { + throw new InternalError(ioe); // should not happen + } + } } return channel; } diff --git a/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java b/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java --- a/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java +++ b/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java @@ -109,6 +109,9 @@ // -- Standard channel operations -- protected void implCloseChannel() throws IOException { + if (!fd.valid()) + return; // nothing to do + // Release and invalidate any locks that we still hold if (fileLockTable != null) { for (FileLock fl: fileLockTable.removeAll()) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Dec 2 10:50:42 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Dec 2014 10:50:42 +0000 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: References: <547ADE20.2060102@oracle.com> <547B4920.2010105@oracle.com> <547B818F.2060600@oracle.com> <547C2C4F.5080705@oracle.com> Message-ID: <547D9982.1040600@oracle.com> On 01/12/2014 19:13, Francis Galiegue wrote: > As I said: an empty path _for which filesystem_? The one associated > with the path you try to .resolveSibling() against or the one of the > path given as an argument? This is what the documentation is not clear > about (without even going to the provider level). > I see your point and answering this comes back to how a custom provider is suppose to behave when it has distinct FileSystem implementations. I need to think about this issue a bit more as changing anything here risks creating inconsistencies between resolve/resolveSibling/relativize so great care is required. Hopefully get back to you in a few days when I find time. -Alan. From fgaliegue at gmail.com Tue Dec 2 13:25:36 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Tue, 2 Dec 2014 14:25:36 +0100 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: <547D9982.1040600@oracle.com> References: <547ADE20.2060102@oracle.com> <547B4920.2010105@oracle.com> <547B818F.2060600@oracle.com> <547C2C4F.5080705@oracle.com> <547D9982.1040600@oracle.com> Message-ID: On Tue, Dec 2, 2014 at 11:50 AM, Alan Bateman wrote: > On 01/12/2014 19:13, Francis Galiegue wrote: >> >> As I said: an empty path _for which filesystem_? The one associated >> with the path you try to .resolveSibling() against or the one of the >> path given as an argument? This is what the documentation is not clear >> about (without even going to the provider level). >> > I see your point and answering this comes back to how a custom provider is > suppose to behave when it has distinct FileSystem implementations. I need to > think about this issue a bit more as changing anything here risks creating > inconsistencies between resolve/resolveSibling/relativize so great care is > required. Hopefully get back to you in a few days when I find time. > > -Alan. Well, I have done a lot of procrastination on the subject for some time already (I have a somewhat working FileSystem implementation over FTP already, and now I'm trying to generalize it) and I have come up with some ideas already. For instance, Paths.resolve(source, other): would work like Path's .resolve(), except that it is guaranteed that the resulting path will be associated to the FileSystem of "source"; of course, it requires that generated Paths for a same provider are consistent between FileSystem instances -- as far as I can see, this is not even a requirement, right? I will get to it in code; I intend to write a library to work around the "user side" of java.nio.file in the same way that at this moment I write a "developer side" library to implement custom filesystems... But all in all, I am quite interested in such a discussion! Regards, -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From brian.burkhalter at oracle.com Wed Dec 3 02:22:59 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 2 Dec 2014 18:22:59 -0800 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: <547D7F7D.5010505@oracle.com> References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> <547D7F7D.5010505@oracle.com> Message-ID: On Dec 2, 2014, at 12:59 AM, Alan Bateman wrote: > I think it would be better to fix the underlying issue, which is that FIS/FOS/RAF will create a FileChannel that is open after the file has been closed. Agreed. > Try the patch below as a starting point. This will create the FileChannel and close it before the reference is handed out. A cleaner solution would be to create the FileChannel in the closed state but it would involve more intrusive changes. > > -Alan > > diff --git a/src/java.base/share/classes/java/io/FileInputStream.java b/src/java.base/share/classes/java/io/FileInputStream.java > --- a/src/java.base/share/classes/java/io/FileInputStream.java > +++ b/src/java.base/share/classes/java/io/FileInputStream.java > @@ -367,6 +367,13 @@ > synchronized (this) { > if (channel == null) { > channel = FileChannelImpl.open(fd, path, true, false, this); > + if (closed) { > + try { > + channel.close(); > + } catch (IOException ioe) { > + throw new InternalError(ioe); // should not happen > + } > + } > } It looks like it?s possible that ?closed? could be ?false? when tested in the if-statement but become ?true? before the return if close() were called on another thread in the minuscule intervening time. Should perhaps the closeLock be used to prevent that? > return channel; Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Dec 3 14:53:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Dec 2014 14:53:06 +0000 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: References: <547ADE20.2060102@oracle.com> <547B4920.2010105@oracle.com> <547B818F.2060600@oracle.com> <547C2C4F.5080705@oracle.com> <547D9982.1040600@oracle.com> Message-ID: <547F23D2.1090101@oracle.com> On 02/12/2014 13:25, Francis Galiegue wrote: > : > Well, I have done a lot of procrastination on the subject for some > time already (I have a somewhat working FileSystem implementation over > FTP already, and now I'm trying to generalize it) and I have come up > with some ideas already. > > For instance, Paths.resolve(source, other): would work like Path's > .resolve(), except that it is guaranteed that the resulting path will > be associated to the FileSystem of "source"; of course, it requires > that generated Paths for a same provider are consistent between > FileSystem instances -- as far as I can see, this is not even a > requirement, right? > > I will get to it in code; I intend to write a library to work around > the "user side" of java.nio.file in the same way that at this moment I > write a "developer side" library to implement custom filesystems... > > But all in all, I am quite interested in such a discussion! > > One potential solution is that resolve(other) should be specified to always return "other" then "other" is associated with a different FileSystem to that of "this". I need to look through the implications of this to ensure that everything would remain consistent. It would mean that resolve would not need to throw ProviderMismatchException too. As I said, give me a few days to find time to think about this. -Alan From brian.burkhalter at oracle.com Wed Dec 3 21:43:08 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Dec 2014 13:43:08 -0800 Subject: RFR 9: 8065570: (bf spec) ByteBuffer.slice() should make it clear that the initial order is BIG_ENDIAN Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8065570 Patch: http://cr.openjdk.java.net/~bpb/8065570/webrev.00/ One interesting thing not part of this patch is that the byte order of the ByteBuffer returned by ByteBuffer.asReadOnlyBuffer() is always BIG_ENDIAN, whereas that of the XBuffer returned by XBuffer.asReadOnlyBuffer() is the byte order of the original XBuffer. This seems inconsistent. For instance, this code sequence ByteBuffer buf = ByteBuffer.allocate(256); buf.order(ByteOrder.LITTLE_ENDIAN); System.out.println(buf.asIntBuffer().asReadOnlyBuffer().order()); System.out.println(buf.asReadOnlyBuffer().asIntBuffer().order()); will print LITTLE_ENDIAN BIG_ENDIAN Thanks, Brian From brian.burkhalter at oracle.com Thu Dec 4 00:00:31 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Dec 2014 16:00:31 -0800 Subject: RFR 9: 8065570: (bf spec) ByteBuffer.slice() should make it clear that the initial order is BIG_ENDIAN In-Reply-To: References: Message-ID: Similarly duplicate() and slice() invoked on a ByteBuffer return a ByteBuffer with byte order BIG_ENDIAN, whereas these methods invoked on an XBuffer (where X != Byte) return an XBuffer with the same byte order as the XBuffer object on which they were invoked. Brian On Dec 3, 2014, at 1:43 PM, Brian Burkhalter wrote: > One interesting thing not part of this patch is that the byte order of the ByteBuffer returned by ByteBuffer.asReadOnlyBuffer() is always BIG_ENDIAN, whereas that of the XBuffer returned by XBuffer.asReadOnlyBuffer() is the byte order of the original XBuffer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at oracle.com Thu Dec 4 12:23:17 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 4 Dec 2014 12:23:17 +0000 Subject: RFR JDK-8066678: java.nio.channels.Channels cleanup In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <550E428F-B7DB-426B-8419-E954522C75DE@oracle.com> Hi everyone, Could you please review my change for JDK-8066678? http://cr.openjdk.java.net/~prappo/8066678/webrev.00/ It's a minor cleanup. Main things fixed: * Substituted Channels.checkNotNull for Objects.Objects.requireNonNull (non-essential difference is the NPE message) * Javadoc fixes Thanks -Pavel From fgaliegue at gmail.com Thu Dec 4 13:42:25 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Thu, 4 Dec 2014 14:42:25 +0100 Subject: RFR 9: 8065570: (bf spec) ByteBuffer.slice() should make it clear that the initial order is BIG_ENDIAN In-Reply-To: References: Message-ID: On Thu, Dec 4, 2014 at 1:00 AM, Brian Burkhalter wrote: > Similarly duplicate() and slice() invoked on a ByteBuffer return a > ByteBuffer with byte order BIG_ENDIAN, whereas these methods invoked on an > XBuffer (where X != Byte) return an XBuffer with the same byte order as the > XBuffer object on which they were invoked. > [...] Ouch! Longstanding bug or design decision? I'd rather say the former, but I'll certainly keep that in mind when I use these methods! -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From chris.hegarty at oracle.com Thu Dec 4 13:59:46 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 4 Dec 2014 13:59:46 +0000 Subject: RFR JDK-8066678: java.nio.channels.Channels cleanup In-Reply-To: <550E428F-B7DB-426B-8419-E954522C75DE@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <550E428F-B7DB-426B-8419-E954522C75DE@oracle.com> Message-ID: <27982D36-12F5-4286-BCD6-B5D4CC30D264@oracle.com> There is a lot of stylistic changes in the webrev. Can you please revert them and leave just the real cleanup? -Chris. On 4 Dec 2014, at 12:23, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8066678? > > http://cr.openjdk.java.net/~prappo/8066678/webrev.00/ > > It's a minor cleanup. Main things fixed: > > * Substituted Channels.checkNotNull for Objects.Objects.requireNonNull > (non-essential difference is the NPE message) > * Javadoc fixes > > Thanks > -Pavel From Alan.Bateman at oracle.com Thu Dec 4 14:01:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 14:01:54 +0000 Subject: RFR JDK-8066678: java.nio.channels.Channels cleanup In-Reply-To: <550E428F-B7DB-426B-8419-E954522C75DE@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <550E428F-B7DB-426B-8419-E954522C75DE@oracle.com> Message-ID: <54806952.2060205@oracle.com> On 04/12/2014 12:23, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8066678? > > http://cr.openjdk.java.net/~prappo/8066678/webrev.00/ > > It's a minor cleanup. Main things fixed: > > * Substituted Channels.checkNotNull for Objects.Objects.requireNonNull > (non-essential difference is the NPE message) > * Javadoc fixes > The change to use Objects.requireNonNull looks okay. Also removing the "open" flag from WritableByteChannelImpl is okay. I don't agree with the javadoc changes, it makes this class inconsistent with the other classes in this area. The changes to use {@code ... } are good. -Alan From Alan.Bateman at oracle.com Thu Dec 4 14:09:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 14:09:03 +0000 Subject: RFR 9: 8065570: (bf spec) ByteBuffer.slice() should make it clear that the initial order is BIG_ENDIAN In-Reply-To: References: Message-ID: <54806AFF.4050509@oracle.com> On 03/12/2014 21:43, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8065570 > Patch: http://cr.openjdk.java.net/~bpb/8065570/webrev.00/ > > One interesting thing not part of this patch is that the byte order of the ByteBuffer returned by ByteBuffer.asReadOnlyBuffer() is always BIG_ENDIAN, whereas that of the XBuffer returned by XBuffer.asReadOnlyBuffer() is the byte order of the original XBuffer. This seems inconsistent. For instance, this code sequence > > ByteBuffer buf = ByteBuffer.allocate(256); > buf.order(ByteOrder.LITTLE_ENDIAN); > System.out.println(buf.asIntBuffer().asReadOnlyBuffer().order()); > System.out.println(buf.asReadOnlyBuffer().asIntBuffer().order()); > > will print > > LITTLE_ENDIAN > BIG_ENDIAN > I think you'll need to dig into inconsistencies before we add any clarifications to the javadoc. I assume any issues date back to JDK 1.4 but we need to check that. I don't have time to dig into myself just now but I believe the original intent was that all new buffers be created in BIG_ENDIAN and that view buffers are tied to whatever the order is of the byte buffer that they are created. -Alan From fgaliegue at gmail.com Thu Dec 4 14:29:56 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Thu, 4 Dec 2014 15:29:56 +0100 Subject: RFR 9: 8065570: (bf spec) ByteBuffer.slice() should make it clear that the initial order is BIG_ENDIAN In-Reply-To: <54806AFF.4050509@oracle.com> References: <54806AFF.4050509@oracle.com> Message-ID: Hello, On Thu, Dec 4, 2014 at 3:09 PM, Alan Bateman wrote: [...]> I think you'll need to dig into inconsistencies before we add any > clarifications to the javadoc. I assume any issues date back to JDK 1.4 but > we need to check that. I don't have time to dig into myself just now but I > believe the original intent was that all new buffers be created in > BIG_ENDIAN and that view buffers are tied to whatever the order is of the > byte buffer that they are created. > While the docs indeed say so (you have to do "back to back" reads but whatever), the problem is that it violates the principle of least surprise; especially since the .as*Buffer() "conversions" don't alter the order at all. I do agree that it should be better documented. -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Thu Dec 4 14:35:50 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 14:35:50 +0000 Subject: RFR 9: 8065570: (bf spec) ByteBuffer.slice() should make it clear that the initial order is BIG_ENDIAN In-Reply-To: References: <54806AFF.4050509@oracle.com> Message-ID: <54807146.6020408@oracle.com> On 04/12/2014 14:29, Francis Galiegue wrote: > : > While the docs indeed say so (you have to do "back to back" reads but > whatever), the problem is that it violates the principle of least > surprise; especially since the .as*Buffer() "conversions" don't alter > the order at all. > > I do agree that it should be better documented. > Hopefully Brian can dig into the history. I don't think there should be any question mark over the view buffers as the spec is clear on that: "The byte order of a view buffer is fixed to be that of its byte buffer at the time that the view is created." It's not as obvious for some of the methods that create new buffers. -Alan. From pavel.rappo at oracle.com Thu Dec 4 14:46:35 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 4 Dec 2014 14:46:35 +0000 Subject: RFR JDK-8066678: java.nio.channels.Channels cleanup In-Reply-To: <54806952.2060205@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <550E428F-B7DB-426B-8419-E954522C75DE@oracle.com> <54806952.2060205@oracle.com> Message-ID: <5DD8D3BD-689A-4A26-A4A8-27B0647AD01D@oracle.com> Chirs, Alan, done in place. The thing I'm still thinking about is this: if (in instanceof FileInputStream && FileInputStream.class.equals(in.getClass())) { return ((FileInputStream)in).getChannel(); } Were there any particular reasons for 'in' to be *exactly* an instance of FileInputStream? As you've seen I changed it safely to: if (in.getClass() == FileInputStream.class) { return ((FileInputStream) in).getChannel(); } But can we simply go a little bit further and change it to just: if (in instanceof FileInputStream) { return ((FileInputStream) in).getChannel(); } ? Does anybody recall why it was that way in the first place? -Pavel > On 4 Dec 2014, at 14:01, Alan Bateman wrote: > > On 04/12/2014 12:23, Pavel Rappo wrote: >> Hi everyone, >> >> Could you please review my change for JDK-8066678? >> >> http://cr.openjdk.java.net/~prappo/8066678/webrev.00/ >> >> It's a minor cleanup. Main things fixed: >> >> * Substituted Channels.checkNotNull for Objects.Objects.requireNonNull >> (non-essential difference is the NPE message) >> * Javadoc fixes >> > The change to use Objects.requireNonNull looks okay. Also removing the "open" flag from WritableByteChannelImpl is okay. > > I don't agree with the javadoc changes, it makes this class inconsistent with the other classes in this area. The changes to use {@code ... } are good. > > -Alan From Alan.Bateman at oracle.com Thu Dec 4 14:54:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 14:54:14 +0000 Subject: RFR JDK-8066678: java.nio.channels.Channels cleanup In-Reply-To: <5DD8D3BD-689A-4A26-A4A8-27B0647AD01D@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <550E428F-B7DB-426B-8419-E954522C75DE@oracle.com> <54806952.2060205@oracle.com> <5DD8D3BD-689A-4A26-A4A8-27B0647AD01D@oracle.com> Message-ID: <54807596.4080609@oracle.com> On 04/12/2014 14:46, Pavel Rappo wrote: > : > > But can we simply go a little bit further and change it to just: > > if (in instanceof FileInputStream) { > return ((FileInputStream) in).getChannel(); > } > ? > > Does anybody recall why it was that way in the first place? I can't see any reason why it wasn't done this way originally, I can only assume it was a concern at the time with classes that extend FileInputStream. -Alan. From Alan.Bateman at oracle.com Thu Dec 4 14:56:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 14:56:14 +0000 Subject: RFR JDK-8066678: java.nio.channels.Channels cleanup In-Reply-To: <5DD8D3BD-689A-4A26-A4A8-27B0647AD01D@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <550E428F-B7DB-426B-8419-E954522C75DE@oracle.com> <54806952.2060205@oracle.com> <5DD8D3BD-689A-4A26-A4A8-27B0647AD01D@oracle.com> Message-ID: <5480760E.70701@oracle.com> On 04/12/2014 14:46, Pavel Rappo wrote: > Chirs, Alan, done in place. The updated webrev looks okay. -Alan From brian.burkhalter at oracle.com Thu Dec 4 19:27:55 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 4 Dec 2014 11:27:55 -0800 Subject: RFR 9: 8065570: (bf spec) ByteBuffer.slice() should make it clear that the initial order is BIG_ENDIAN In-Reply-To: <54806AFF.4050509@oracle.com> References: <54806AFF.4050509@oracle.com> Message-ID: On Dec 4, 2014, at 6:09 AM, Alan Bateman wrote: > I think you'll need to dig into inconsistencies before we add any clarifications to the javadoc. I concur; I?ll try to run it down. I think in the end it will devolve to one of two outcomes: 1) only update the documentation to match the behavior, or 2) if the behavior is wrong, correct it and then update the documentation as needed. > I assume any issues date back to JDK 1.4 but we need to check that. I don't have time to dig into myself just now but I believe the original intent was that all new buffers be created in BIG_ENDIAN and that view buffers are tied to whatever the order is of the byte buffer that they are created. In ignorance of the original design intent, as a user I would naively expect the buffers returned by asReadOnlyBuffer(), duplicate(), and slice() to have the same byte order as the buffer on which the methods were invoked at the moment of invocation. I concur that the situation with respect to view buffers is however quite clear. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcins at microsoft.com Fri Dec 5 20:13:35 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Fri, 5 Dec 2014 20:13:35 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <5471B3CA.6030908@oracle.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> <545E1017.5040603@oracle.com> <47cfbda045694bfca3ab2eda25f63282@BLUPR03MB136.namprd03.prod.outlook.com> <5464F276.8040800@oracle.com> <5471B3CA.6030908@oracle.com> Message-ID: From: Alan Bateman [mailto:Alan.Bateman at oracle.com] On 14/11/2014 16:51, Kirk Shoop (MS OPEN TECH) wrote: From: Alan Bateman [mailto:Alan.Bateman at oracle.com] I think this looks much better. Great! One thing that needs a closer look is the loop around TransmitFile. If it fails on the second or subsequent call then transferTo will fail after already sending transmitting bytes. For transferTo then it's okay to complete without having transmitted all bytes and maybe it would be better to just cap it at 2GB. Any robust code using transferTo should check the return value. (BTW: You can use java_lang_Integer_MAX_VALUE to avoid the repeating the constant). Good point, Valery removed the loop. In transferToDirectly then I don't think you need to check if the target is a SelectableChannel if you move call to nd.canTransferToDirectly to just above where it handles SelChImpl. Done. One suggestion is to top transferToDirectlyEnabled and instead jave canTransferToDirectly return true then the property is enabled and the target change is SelectableChannel configured blocking. Done. A minor comment is that transferToDirectlyChangesChannelPosition is a bit inconsistent with methods like needPositionLock so you might be able to come up with something a bit closer to that, transferDirectNeedsPositionLock maybe? Valery chose 'transferToDirectlyNeedsPositionRestoring', but this can be changed. While looking at this, I wondered, could the position lock and position manipulation in Java be skipped altogether if 'Java_sun_nio_ch_FileChannelImpl_transferTo0' used 'Java_sun_nio_ch_FileChannelImpl_position0' to restore the position to the original point? A few style/formatting issues that we can sort out later, otherwise the approach looks okay to me. Happy to take those changes anytime. Sorry for the delay getting back to you on this, I've been busy with other things. I think the updated version looks good and you've addressed the issues that I was concerned about. One other potential issue that came to mind later is that the blocking mode of the SocketChannel could change to non-blocking at or around the time that transferTo is called. It would be possible to restructure this to hold the blockingLock but I think it makes the locking more complicated. Worst case with this "bug" is that transferTo blocks at around the time the blocking mode is changed to non-blocking. There is a bigger (and longstanding) issue in this area related to async close of the target channel during a transfer and if/when that gets looked at then I think it is the time to address the blocking lock issue too. I had to re-base your patch to get it working with the current jdk9/dev tip, that is only because of other recent changes in this area. I tweaked some minor formatting issues and used the opportunity to replace the imports that use wildcards. I don't have a strong opinion on the method to determine if the position changes except that transferToDirectlyNeedsPositionLock is a bit more consistent with the current naming. Here is the updated patch (only minor edits as I said): http://cr.openjdk.java.net/~alanb/8064407/webrev/ I've run this patch through our build+test system to make sure that it works on the 7+ platforms that we normally care about and I don't see any issues. I've also run the jdk_nio tests with the property enabled so that all tests using transferTo use TransmitFile when the channel is configured blocking. Let me know if you are okay with this? -Alan Kirk has been sick, but the answer is Yes. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Dec 5 22:06:39 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Dec 2014 14:06:39 -0800 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: <547D7F7D.5010505@oracle.com> References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> <547D7F7D.5010505@oracle.com> Message-ID: <9D640615-7CFA-46E6-BC97-C87527B8EA44@oracle.com> On Dec 2, 2014, at 12:59 AM, Alan Bateman wrote: > Try the patch below as a starting point. This will create the FileChannel and close it before the reference is handed out. A cleaner solution would be to create the FileChannel in the closed state but it would involve more intrusive changes. Here?s an updated patch which extends Alan?s suggested patch: http://cr.openjdk.java.net/~bpb/8025619/webrev.01/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Fri Dec 5 22:44:22 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 5 Dec 2014 23:44:22 +0100 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it Message-ID: Witness this main(): public static void main(final String... args) throws IOException { final Path path = Paths.get("/home/fge/tmp/XXX"); try ( final InputStream in = Files.newInputStream(path); ) { final byte[] buf = new byte[1024]; int bytesRead; while ((bytesRead = in.read(buf)) != -1) System.out.printf("%d bytes read\n", bytesRead); } } On my system, "/home/fge/tmp/XXX" is a directory. I'd have expected that it failed when I tried and opened the stream on it, except that the stacktrace I got is: Exception in thread "main" java.io.IOException: Is a directory at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.FileDispatcherImpl.read(FileDispatcherImpl.java:46) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:197) at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:149) at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:65) at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109) at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) at java.io.InputStream.read(InputStream.java:101) at Main.main(Main.java:36) [...] And Main.java:36 is in.read(buf)! FWIW, this is Linux (Ubuntu 14.10), 64bit, x86_64. Looking at all exceptions inheriting FileSystemException, in fact I see no equivalent to EISDIR anyway... Wouldn't it be worth it to define IsDirectoryException or the like inheriting FileSystemException and make the API fail with this exception when attempting to open any kind of *Stream/*Channel on it? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From fgaliegue at gmail.com Fri Dec 5 23:18:20 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 6 Dec 2014 00:18:20 +0100 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: [...] > > FWIW, this is Linux (Ubuntu 14.10), 64bit, x86_64. > > Looking at all exceptions inheriting FileSystemException, in fact I > see no equivalent to EISDIR anyway... > By the way, this is running 1.7.0u72 from Oracle; the result is the same with 1.8.0u25. I've had a report of a similar error on Mac OS X 10.10.1, 1.8.0u25. >From a cursory analysis of the stack trace, it seems to me as the implementation is common to both of them, and that the stream is not actually opened until the first time it is read, and that open(2) returns -EISDIR; hence the error message... -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From fgaliegue at gmail.com Fri Dec 5 23:32:59 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 6 Dec 2014 00:32:59 +0100 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: On Sat, Dec 6, 2014 at 12:18 AM, Francis Galiegue wrote: > [...] > > From a cursory analysis of the stack trace, it seems to me as the > implementation is common to both of them, and that the stream is not > actually opened until the first time it is read, and that open(2) > returns -EISDIR; hence the error message... > Correction: read(2) can also return that. So it seems that either a stat(2) or an lstat(2) is missing before returning the input stream... -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From brian.burkhalter at oracle.com Fri Dec 5 23:33:07 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Dec 2014 15:33:07 -0800 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: On Dec 5, 2014, at 3:18 PM, Francis Galiegue wrote: > By the way, this is running 1.7.0u72 from Oracle; the result is the > same with 1.8.0u25. > > I've had a report of a similar error on Mac OS X 10.10.1, 1.8.0u25. Same thing occurs on Mac OS 10.9.5 running Java 9-dev. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Fri Dec 5 23:38:43 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 6 Dec 2014 00:38:43 +0100 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: Hello, On Sat, Dec 6, 2014 at 12:33 AM, Brian Burkhalter wrote: [...] > > Same thing occurs on Mac OS 10.9.5 running Java 9-dev. > Well, I've just tried to open a new OutputStream; this time it does fail on .newOutputStream(), not when attempting to write to it... -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From brian.burkhalter at oracle.com Fri Dec 5 23:45:59 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Dec 2014 15:45:59 -0800 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: On Dec 5, 2014, at 3:38 PM, Francis Galiegue wrote: > On Sat, Dec 6, 2014 at 12:33 AM, Brian Burkhalter > wrote: > [...] >> >> Same thing occurs on Mac OS 10.9.5 running Java 9-dev. >> > > Well, I've just tried to open a new OutputStream; this time it does > fail on .newOutputStream(), not when attempting to write to it... Well, I don?t have the background in this area to know the history or design intent, but to me it seems preferable to have fail fast behavior such as that apparently implemented by newOutputStream. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Fri Dec 5 23:53:00 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 6 Dec 2014 00:53:00 +0100 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: On Sat, Dec 6, 2014 at 12:45 AM, Brian Burkhalter wrote: [...] > > Well, I don?t have the background in this area to know the history or design > intent, but to me it seems preferable to have fail fast behavior such as > that apparently implemented by newOutputStream. > Agreed on that; also, it'd be really nice to have an exception such as IsDirectoryException or the like for such cases. -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From brian.burkhalter at oracle.com Fri Dec 5 23:58:44 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Dec 2014 15:58:44 -0800 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: On Dec 5, 2014, at 3:53 PM, Francis Galiegue wrote: > Agreed on that; also, it'd be really nice to have an exception such as > IsDirectoryException or the like for such cases. Or ?NotFileException? if the methods in question are supported for files only. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Sat Dec 6 00:01:38 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Dec 2014 16:01:38 -0800 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: <0E6E9B04-B74F-40C7-A6D6-ADD014DA769C@oracle.com> On Dec 5, 2014, at 3:58 PM, Brian Burkhalter wrote: > On Dec 5, 2014, at 3:53 PM, Francis Galiegue wrote: > >> Agreed on that; also, it'd be really nice to have an exception such as >> IsDirectoryException or the like for such cases. > > Or ?NotFileException? if the methods in question are supported for files only. Actually this suggestion is not good as ?file? subsumes regular files, directories, and links. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Sat Dec 6 00:07:54 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 6 Dec 2014 01:07:54 +0100 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: <0E6E9B04-B74F-40C7-A6D6-ADD014DA769C@oracle.com> References: <0E6E9B04-B74F-40C7-A6D6-ADD014DA769C@oracle.com> Message-ID: On Sat, Dec 6, 2014 at 1:01 AM, Brian Burkhalter wrote: [...] > > > Actually this suggestion is not good as ?file? subsumes regular files, > directories, and links. > And, on Unix systems, named pipes, character/block devices etc; all of which can be read from/written to. I do believe IsDirectoryException is on the right track here. -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From fgaliegue at gmail.com Sat Dec 6 02:55:53 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 6 Dec 2014 03:55:53 +0100 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: On Fri, Dec 5, 2014 at 11:44 PM, Francis Galiegue wrote: > Witness this main(): > Want to have some more fun? On Windows, a similar piece of code seems to throw AccessDeniedException... When trying to open the stream! Link to SO "question": http://stackoverflow.com/q/27327783/1093528 -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Sat Dec 6 10:41:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 06 Dec 2014 10:41:44 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> <545E1017.5040603@oracle.com> <47cfbda045694bfca3ab2eda25f63282@BLUPR03MB136.namprd03.prod.outlook.com> <5464F276.8040800@oracle.com> <5471B3CA.6030908@oracle.com> Message-ID: <5482DD68.6020802@oracle.com> On 05/12/2014 20:13, Martin Sawicki (MS OPEN TECH) wrote: > > Kirk has been sick, but the answer is Yes. > Thanks, I will get this pushed. Just to double check, is the attribution the same as it was for the loopback work? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Dec 6 11:46:56 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 06 Dec 2014 11:46:56 +0000 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: <9D640615-7CFA-46E6-BC97-C87527B8EA44@oracle.com> References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> <547D7F7D.5010505@oracle.com> <9D640615-7CFA-46E6-BC97-C87527B8EA44@oracle.com> Message-ID: <5482ECB0.9050309@oracle.com> On 05/12/2014 22:06, Brian Burkhalter wrote: > : > > Here?s an updated patch which extends Alan?s suggested patch: > > http://cr.openjdk.java.net/~bpb/8025619/webrev.01/ > > I think you need to make channel volatile, this also means you can change getChannel() to use the double-checked locking idiom. You can make closed final. The changes to FileKey aren't strictly required but shouldn't be an issue. I think the test should assert that the channel is closed. There isn't anything special with tryLock but if you want to attempt a few operations to checking that ClosedChannelException is thrown then that would be good. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Dec 6 12:07:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 06 Dec 2014 12:07:02 +0000 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: <5482F166.9050300@oracle.com> On 05/12/2014 22:44, Francis Galiegue wrote: > Witness this main(): > > public static void main(final String... args) > throws IOException > { > final Path path = Paths.get("/home/fge/tmp/XXX"); > try ( > final InputStream in = Files.newInputStream(path); > ) { > final byte[] buf = new byte[1024]; > int bytesRead; > while ((bytesRead = in.read(buf)) != -1) > System.out.printf("%d bytes read\n", bytesRead); > } > } > > On my system, "/home/fge/tmp/XXX" is a directory. I'd have expected > that it failed when I tried and opened the stream on it, except that > the stacktrace I got is: > > Exception in thread "main" java.io.IOException: Is a directory > at sun.nio.ch.FileDispatcherImpl.read0(Native Method) > It's not prohibited by the spec because directories can be opened as regular files on some platforms. So what you are seeing it just platform specific behavio. This is clearly not obvious behavior so we should looking at using fstat after opening a file for read access to avoid the confusion (at least on platforms where we can open a directory for reading but where reading is not actually allowed). I will create a bug for this. -Alan. From Alan.Bateman at oracle.com Sat Dec 6 12:08:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 06 Dec 2014 12:08:03 +0000 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: Message-ID: <5482F1A3.5020300@oracle.com> On 05/12/2014 23:45, Brian Burkhalter wrote: > > Well, I don?t have the background in this area to know the history or > design intent, but to me it seems preferable to have fail fast > behavior such as that apparently implemented by newOutputStream. > newOutputStream doesn't actually do anything special here, it's just that the underlying open will fail on Linux and other platforms when you attempt to open a directory for write access. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Sat Dec 6 12:44:05 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 6 Dec 2014 13:44:05 +0100 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: <5482F166.9050300@oracle.com> References: <5482F166.9050300@oracle.com> Message-ID: On Sat, Dec 6, 2014 at 1:07 PM, Alan Bateman wrote: [...] > It's not prohibited by the spec because directories can be opened as regular > files on some platforms. So what you are seeing it just platform specific > behavio[r]. > OK... By the way, on Windows system the code I posted (with a correct path, of course) throws AccessDeniedException when attempting to open! I do believe that a IsDirectoryException should be created for such cases (as an "optional specific exception" as the documentation says). -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From marcins at microsoft.com Sat Dec 6 13:17:57 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Sat, 6 Dec 2014 13:17:57 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <5482DD68.6020802@oracle.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> <545E1017.5040603@oracle.com> <47cfbda045694bfca3ab2eda25f63282@BLUPR03MB136.namprd03.prod.outlook.com> <5464F276.8040800@oracle.com> <5471B3CA.6030908@oracle.com> <5482DD68.6020802@oracle.com> Message-ID: From: Alan Bateman [mailto:Alan.Bateman at oracle.com] On 05/12/2014 20:13, Martin Sawicki (MS OPEN TECH) wrote: Kirk has been sick, but the answer is Yes. Thanks, I will get this pushed. Just to double check, is the attribution the same as it was for the loopback work? -Alan Yes Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Dec 6 21:40:58 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 06 Dec 2014 21:40:58 +0000 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: References: <5482F166.9050300@oracle.com> Message-ID: <548377EA.6010104@oracle.com> On 06/12/2014 12:44, Francis Galiegue wrote: > : > OK... By the way, on Windows system the code I posted (with a correct > path, of course) throws AccessDeniedException when attempting to open! > Yes, Windows specific behavior where it fails with "Access Denied" when you attempt to open a directory. -Alan. From fgaliegue at gmail.com Sun Dec 7 09:21:20 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sun, 7 Dec 2014 10:21:20 +0100 Subject: Bug or not bug? Files.newInputStream() on a Path which is a directory does not fail until you read from it In-Reply-To: <548377EA.6010104@oracle.com> References: <5482F166.9050300@oracle.com> <548377EA.6010104@oracle.com> Message-ID: [...]>> : >> OK... By the way, on Windows system the code I posted (with a correct >> path, of course) throws AccessDeniedException when attempting to open! >> > Yes, Windows specific behavior where it fails with "Access Denied" when you > attempt to open a directory. > Sorry, but I do not buy this argument at all. The JRE is supposed to abstract the OS difference away from its user. You know very well that on some OSes you cannot open a directory for read, and you know how to detect that, so why don't you do the work for the user here and throw an appropriate exception? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From weijun.wang at oracle.com Mon Dec 8 09:37:53 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 8 Dec 2014 17:37:53 +0800 Subject: Path of "." and "" Message-ID: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> Path p1 = Paths.get("."); Path p2 = Paths.get("./s"); Then p2.startsWith(p1) is true. If I normalize them, p1 becomes "", p2 becomes "s", and p2.startsWith(p1) is false. I know it's because after normalizing, p1 has an element which is "", and p2 has an element which is "s", therefore one array does not starts with the other. Maybe p1 should be normalized to no element at all? And what is the best way to check if one path is inside another? I do not want to call toAbsolutePath(). Thanks Max From fgaliegue at gmail.com Mon Dec 8 09:55:20 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 8 Dec 2014 10:55:20 +0100 Subject: Path of "." and "" In-Reply-To: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> Message-ID: On Mon, Dec 8, 2014 at 10:37 AM, Wang Weijun wrote: > Path p1 = Paths.get("."); > Path p2 = Paths.get("./s"); > > Then p2.startsWith(p1) is true. > > If I normalize them, p1 becomes "", p2 becomes "s", and p2.startsWith(p1) is false. > > I know it's because after normalizing, p1 has an element which is "", and p2 has an element which is "s", therefore one array does not starts with the other. Maybe p1 should be normalized to no element at all? > Indeed, it seems logical that p1 has no elements at all, nothing, not even a root here. But then you are referring to UnixPath, right? My own Path implementation does not use one array for the whole name, but one element for the root and one element per name component (in fact, it is so generic that it is final, no less -- and it can even have empty name elements should there be some bizarre fs out there which accepts that). The end result is the same anyway: it gives the same results as you, which is logical. > And what is the best way to check if one path is inside another? I do not want to call toAbsolutePath(). > With Unix that would even be .toRealPath() (yes, it throws an IOE). But that proves that Path is abstract and you don't really know that it is something real unless you "dereference" it... And once you have done that, collect all elements into Lists and call Collections.indexOfSublist()? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Mon Dec 8 10:00:56 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 10:00:56 +0000 Subject: Path of "." and "" In-Reply-To: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> Message-ID: <548576D8.60400@oracle.com> On 08/12/2014 09:37, Wang Weijun wrote: > Path p1 = Paths.get("."); > Path p2 = Paths.get("./s"); > > Then p2.startsWith(p1) is true. > > If I normalize them, p1 becomes "", p2 becomes "s", and p2.startsWith(p1) is false. > > I know it's because after normalizing, p1 has an element which is "", and p2 has an element which is "s", therefore one array does not starts with the other. Maybe p1 should be normalized to no element at all? > > And what is the best way to check if one path is inside another? I do not want to call toAbsolutePath(). > If you iterate from 0 to name count and call subpath then you it will give you the set of tails. Use that with p2.startWith(p1) then I think it should do what you want. -Alan. From weijun.wang at oracle.com Mon Dec 8 10:37:51 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 8 Dec 2014 18:37:51 +0800 Subject: Path of "." and "" In-Reply-To: <548576D8.60400@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> Message-ID: <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> > On Dec 8, 2014, at 18:00, Alan Bateman wrote: > > On 08/12/2014 09:37, Wang Weijun wrote: >> Path p1 = Paths.get("."); >> Path p2 = Paths.get("./s"); >> >> Then p2.startsWith(p1) is true. >> >> If I normalize them, p1 becomes "", p2 becomes "s", and p2.startsWith(p1) is false. >> >> I know it's because after normalizing, p1 has an element which is "", and p2 has an element which is "s", therefore one array does not starts with the other. Maybe p1 should be normalized to no element at all? >> >> And what is the best way to check if one path is inside another? I do not want to call toAbsolutePath(). >> > If you iterate from 0 to name count and call subpath then you it will give you the set of tails. Use that with p2.startWith(p1) then I think it should do what you want. Can you be more detailed? For the 2 paths above (after normalized) there is only subpath(0,1) that computes and the result is the same as the full path. I also noticed that even if the startsWith method returns false, the p1.relativize(p2) returns a simple "s". Also, the p1.relativize(p1) is empty but its getNameCount() is 1. Why is there no isEmpty()? I'll need to write a bunch of helper methods. --Max > > -Alan. From fgaliegue at gmail.com Mon Dec 8 10:51:57 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 8 Dec 2014 11:51:57 +0100 Subject: Path of "." and "" In-Reply-To: <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> Message-ID: On Mon, Dec 8, 2014 at 11:37 AM, Wang Weijun wrote: [...] > > Also, the p1.relativize(p1) is empty but its getNameCount() is 1. > That is clearly a bug! Good find... -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From weijun.wang at oracle.com Mon Dec 8 10:55:28 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 8 Dec 2014 18:55:28 +0800 Subject: Path of "." and "" In-Reply-To: References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> Message-ID: > On Dec 8, 2014, at 18:51, Francis Galiegue wrote: > > On Mon, Dec 8, 2014 at 11:37 AM, Wang Weijun wrote: > [...] >> >> Also, the p1.relativize(p1) is empty but its getNameCount() is 1. >> > > That is clearly a bug! Good find... Well, they said no. An empty path is defined as a path with one empty element. I am just complaining a lot is not intuitive. Another thing is that "/" is really empty, which has no element at all. --Max > > -- > Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge > JSON Schema in Java: http://json-schema-validator.herokuapp.com > Parsers in pure Java: https://github.com/parboiled1/grappa (redde > Caesaris: https://github.com/sirthias) From fgaliegue at gmail.com Mon Dec 8 10:58:00 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 8 Dec 2014 11:58:00 +0100 Subject: Path of "." and "" In-Reply-To: References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> Message-ID: On Mon, Dec 8, 2014 at 11:55 AM, Wang Weijun wrote: > >> On Dec 8, 2014, at 18:51, Francis Galiegue wrote: >> >> On Mon, Dec 8, 2014 at 11:37 AM, Wang Weijun wrote: >> [...] >>> >>> Also, the p1.relativize(p1) is empty but its getNameCount() is 1. >>> >> >> That is clearly a bug! Good find... > > Well, they said no. > > An empty path is defined as a path with one empty element. > ... Which is illegal on any OS I can think of. No, this is clearly a bug to my eyes. -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Mon Dec 8 11:11:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 11:11:09 +0000 Subject: Path of "." and "" In-Reply-To: References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> Message-ID: <5485874D.2020908@oracle.com> On 08/12/2014 10:55, Wang Weijun wrote: >> : >> >> I am just complaining a lot is not intuitive. The long standing issue with the empty path is just trying to keep things consistent. >> >> Another thing is that "/" is really empty, which has no element at all. >> "/" is typically a path with a root component and zero name elements. -Alan. From Alan.Bateman at oracle.com Mon Dec 8 11:22:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 11:22:03 +0000 Subject: Path of "." and "" In-Reply-To: <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> Message-ID: <548589DB.6050203@oracle.com> On 08/12/2014 10:37, Wang Weijun wrote: > : > Can you be more detailed? I don't know how normalize comes into what you are doing but this should do it, ignoring the corner cases of where you have root components or "" paths: int count = p1.getNameCount(); for (int i=0; i From fgaliegue at gmail.com Mon Dec 8 15:07:44 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 8 Dec 2014 16:07:44 +0100 Subject: Javadoc does not specify... Is null allowed in Files.setAttribute() as an attribute value? Message-ID: It is very unclear whether it is. For instance, for a DosFileAttributeView, it will obviously throw an NPE each time we try to set one of its specific attributes (hidden, system, archive, readonly) due to attempted unboxing. Similarly, it does not seem to make much sense for a UserDefinedAttributeView. The closest exception that I can see is IllegalArgumentException since it is clearly an "inappropriate value" for such a case. Yet when I do try to set this attribute (I use Linux) with null as an argument I get an NPE. So, shouldn't NPE be specified as a possible exception in the documentation, or is null just not allowed at all, in which case it should be mentioned when describing the value parameter? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Mon Dec 8 15:27:59 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 15:27:59 +0000 Subject: Javadoc does not specify... Is null allowed in Files.setAttribute() as an attribute value? In-Reply-To: References: Message-ID: <5485C37F.1090903@oracle.com> On 08/12/2014 15:07, Francis Galiegue wrote: > : > > So, shouldn't NPE be specified as a possible exception in the > documentation, or is null just not allowed at all, in which case it > should be mentioned when describing the value parameter? NPE is specified in the package documentation (general exceptions section), this was to avoid the noise of adding a @throws NPE to every method. So assume null is not allow unless it explicitly specified to be allowed. -Alan. From fgaliegue at gmail.com Mon Dec 8 15:30:01 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 8 Dec 2014 16:30:01 +0100 Subject: Javadoc does not specify... Is null allowed in Files.setAttribute() as an attribute value? In-Reply-To: <5485C37F.1090903@oracle.com> References: <5485C37F.1090903@oracle.com> Message-ID: On Mon, Dec 8, 2014 at 4:27 PM, Alan Bateman wrote: [...] > > NPE is specified in the package documentation (general exceptions section), > this was to avoid the noise of adding a @throws NPE to every method. > OK, I should really re-read all the javadoc once again (I missed that "empty path" stuff but I ultimately think it's a design error -- nevermind). In that case, and more generally, why doesn't the JDK use JSR 305? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Mon Dec 8 15:34:28 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 15:34:28 +0000 Subject: Javadoc does not specify... Is null allowed in Files.setAttribute() as an attribute value? In-Reply-To: References: <5485C37F.1090903@oracle.com> Message-ID: <5485C504.5030009@oracle.com> On 08/12/2014 15:30, Francis Galiegue wrote: > OK, I should really re-read all the javadoc once again (I missed that > "empty path" stuff but I ultimately think it's a design error -- > nevermind). The empty path is difficult, we didn't original have it but not having it lead to way more problems. I don't have time now to go through all the history. > > In that case, and more generally, why doesn't the JDK use JSR 305? > If it's not in the JDK then the JDK can't use it. From fgaliegue at gmail.com Mon Dec 8 15:38:43 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 8 Dec 2014 16:38:43 +0100 Subject: Javadoc does not specify... Is null allowed in Files.setAttribute() as an attribute value? In-Reply-To: <5485C504.5030009@oracle.com> References: <5485C37F.1090903@oracle.com> <5485C504.5030009@oracle.com> Message-ID: On Mon, Dec 8, 2014 at 4:34 PM, Alan Bateman wrote: > On 08/12/2014 15:30, Francis Galiegue wrote: >> >> OK, I should really re-read all the javadoc once again (I missed that >> "empty path" stuff but I ultimately think it's a design error -- >> nevermind). > > The empty path is difficult, we didn't original have it but not having it > lead to way more problems. I don't have time now to go through all the > history. > I will look it up when I have time, no worries... I won't bug the list anymore with that ;) >> >> In that case, and more generally, why doesn't the JDK use JSR 305? >> > If it's not in the JDK then the JDK can't use it. > OK, then I rephrase my question: why isn't JSR 305 in the JDK? It has been there for a handful of years, is well specified, is used by a good number of very useful tools, is immensely useful as documentation, yet it isnt there. -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From cgdecker at google.com Mon Dec 8 18:10:30 2014 From: cgdecker at google.com (Colin Decker) Date: Mon, 08 Dec 2014 18:10:30 +0000 Subject: Javadoc does not specify... Is null allowed in Files.setAttribute() as an attribute value? References: <5485C37F.1090903@oracle.com> <5485C504.5030009@oracle.com> Message-ID: On Mon Dec 08 2014 at 10:39:32 AM Francis Galiegue wrote: > > OK, then I rephrase my question: why isn't JSR 305 in the JDK? It has > been there for a handful of years, is well specified, is used by a > good number of very useful tools, is immensely useful as > documentation, yet it isnt there. I don't think JSR 305 is well-specified. There isn't even Javadoc for most of the annotations. There are differing interpretations of its annotations, particularly with regard to things like what @Nullable on a parameter of an interface method means (do all implementations of that interface have to accept null?). Not to mention that type annotations change things quite a bit. -- > Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge > JSON Schema in Java: http://json-schema-validator.herokuapp.com > Parsers in pure Java: https://github.com/parboiled1/grappa (redde > Caesaris: https://github.com/sirthias) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Mon Dec 8 18:45:11 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 8 Dec 2014 19:45:11 +0100 Subject: Javadoc does not specify... Is null allowed in Files.setAttribute() as an attribute value? In-Reply-To: References: <5485C37F.1090903@oracle.com> <5485C504.5030009@oracle.com> Message-ID: On Mon, Dec 8, 2014 at 7:10 PM, Colin Decker wrote: [...] > > > I don't think JSR 305 is well-specified. There isn't even Javadoc for most > of the annotations. There are differing interpretations of its annotations, > particularly with regard to things like what @Nullable on a parameter of an > interface method means (do all implementations of that interface have to > accept null?). Not to mention that type annotations change things quite a > bit. > What package are you referring to here? I find the one provided by com.googlecode.findbugs to be pretty well documented... As to differing interpretations I guess this is a bug to be reported to the package authors? Oh, and unrelated, but since you seem to be working on jimfs I have something which you might be interested in, and this is right in this list's topic: https://github.com/fge/java7-fs-base. In not even a week, with this package, I could implement a working FileSystem over a big-name online file storage vendor... And others are easy to program as well. Feedback more than welcome... Although I admit that the doc is seriously lacking. Issues on github, please, but I will take any and all inputs into account! Regards, -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Mon Dec 8 21:39:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 21:39:01 +0000 Subject: Path of "." and "" In-Reply-To: References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> Message-ID: <54861A75.1060603@oracle.com> On 08/12/2014 10:55, Wang Weijun wrote: >> On Dec 8, 2014, at 18:51, Francis Galiegue wrote: >> >> On Mon, Dec 8, 2014 at 11:37 AM, Wang Weijun wrote: >> [...] >>> Also, the p1.relativize(p1) is empty but its getNameCount() is 1. >>> >> That is clearly a bug! Good find... > Well, they said no. > > An empty path is defined as a path with one empty element. > > That's right, and getNameCount should return 1 for this case. -Alan. From Alan.Bateman at oracle.com Mon Dec 8 21:42:33 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 21:42:33 +0000 Subject: Path of "." and "" In-Reply-To: <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> Message-ID: <54861B49.8040906@oracle.com> On 08/12/2014 10:37, Wang Weijun wrote: >> : >> >> I also noticed that even if the startsWith method returns false, the p1.relativize(p2) returns a simple "s". >> For this example then p1 is the empty path and p2 is "s". Accessing a file using the empty path is equivalent to accessing the default directory. The relative path to get from the default directory to "s" is "s", so I think what you have is correct. -Alan. From brian.burkhalter at oracle.com Mon Dec 8 22:28:17 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 Dec 2014 14:28:17 -0800 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: <5482ECB0.9050309@oracle.com> References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> <547D7F7D.5010505@oracle.com> <9D640615-7CFA-46E6-BC97-C87527B8EA44@oracle.com> <5482ECB0.9050309@oracle.com> Message-ID: On Dec 6, 2014, at 3:46 AM, Alan Bateman wrote: > On 05/12/2014 22:06, Brian Burkhalter wrote: >> : >> >> Here?s an updated patch which extends Alan?s suggested patch: >> >> http://cr.openjdk.java.net/~bpb/8025619/webrev.01/ >> > > I think you need to make channel volatile, this also means you can change getChannel() to use the double-checked locking idiom. > > You can make closed final. > > The changes to FileKey aren't strictly required but shouldn't be an issue. > > I think the test should assert that the channel is closed. There isn't anything special with tryLock but if you want to attempt a few operations to checking that ClosedChannelException is thrown then that would be good. Here?s an updated patch incorporating the foregoing suggested changes: http://cr.openjdk.java.net/~bpb/8025619/webrev.02/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Dec 9 00:07:16 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 9 Dec 2014 08:07:16 +0800 Subject: Path of "." and "" In-Reply-To: <54861B49.8040906@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> <54861B49.8040906@oracle.com> Message-ID: > On Dec 9, 2014, at 05:42, Alan Bateman wrote: > > On 08/12/2014 10:37, Wang Weijun wrote: >>> : >>> >>> I also noticed that even if the startsWith method returns false, the p1.relativize(p2) returns a simple "s". >>> > For this example then p1 is the empty path and p2 is "s". Accessing a file using the empty path is equivalent to accessing the default directory. The relative path to get from the default directory to "s" is "s", so I think what you have is correct. Yes, but why doesn't a path inside the default directory start with the directory itself? Or does this mean the current normalized form is still not the most normalized one? Another thing I see is that "..".relativize("x") is "../x", while actually it should be "pwd/x". Of course we don't know what "pwd" is, but why not throw an exception? --Max > > -Alan. From Alan.Bateman at oracle.com Tue Dec 9 08:14:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Dec 2014 08:14:48 +0000 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> <547D7F7D.5010505@oracle.com> <9D640615-7CFA-46E6-BC97-C87527B8EA44@oracle.com> <5482ECB0.9050309@oracle.com> Message-ID: <5486AF78.30601@oracle.com> On 08/12/2014 22:28, Brian Burkhalter wrote: > : > > Here?s an updated patch incorporating the foregoing suggested changes: > > http://cr.openjdk.java.net/~bpb/8025619/webrev.02/ > > > This looks better except for getChannel which isn't right in this iteation. I think it's best to change this to use the double-checked locking idiom, this will give something like: FileChannel fc = this.channel; if (fc == null) { synchornized (this) { fc = this.channel; if (fc == null) { this.channel = fc = FileChannelImpl.open(...); : } } } return fc; A minor comment but you can drop the initializing of channel to null (to avoid a needless volatile write). In close then you can eliminate a volatile-read with FileChannel fc = channel; if (fc != null) fc.close(); In the test then it would be good to assert !fc.isOpen(); The tryLock is still a bit odd, shouldn't that be checking for ClosedChannelException too? An alternative name for the test is GetClosedChannel if you are looking for another name. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Dec 9 08:25:30 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Dec 2014 08:25:30 +0000 Subject: Path of "." and "" In-Reply-To: References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> <54861B49.8040906@oracle.com> Message-ID: <5486B1FA.6070607@oracle.com> On 09/12/2014 00:07, Wang Weijun wrote: > : > > Another thing I see is that "..".relativize("x") is "../x", while actually it should be "pwd/x". Of course we don't know what "pwd" is, but why not throw an exception? > It should throw IAE for this case, can you create a bug for this? -Alan From weijun.wang at oracle.com Tue Dec 9 08:31:28 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 9 Dec 2014 16:31:28 +0800 Subject: Path of "." and "" In-Reply-To: <5486B1FA.6070607@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> <54861B49.8040906@oracle.com> <5486B1FA.6070607@oracle.com> Message-ID: Finally, I found a bug, not a feature. :-) https://bugs.openjdk.java.net/browse/JDK-8066943 filed. --Max > On Dec 9, 2014, at 16:25, Alan Bateman wrote: > > On 09/12/2014 00:07, Wang Weijun wrote: >> : >> >> Another thing I see is that "..".relativize("x") is "../x", while actually it should be "pwd/x". Of course we don't know what "pwd" is, but why not throw an exception? >> > It should throw IAE for this case, can you create a bug for this? > > -Alan From brian.burkhalter at oracle.com Tue Dec 9 20:11:19 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 Dec 2014 12:11:19 -0800 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: <5486AF78.30601@oracle.com> References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> <547D7F7D.5010505@oracle.com> <9D640615-7CFA-46E6-BC97-C87527B8EA44@oracle.com> <5482ECB0.9050309@oracle.com> <5486AF78.30601@oracle.com> Message-ID: <9B02C8B6-61A1-4FBD-B0DD-361EA4F3CCD5@oracle.com> On Dec 9, 2014, at 12:14 AM, Alan Bateman wrote: > This looks better except for getChannel which isn't right in this iteation. I think it's best to change this to use the double-checked locking idiom, this will give something like: > > FileChannel fc = this.channel; > if (fc == null) { > synchornized (this) { > fc = this.channel; > if (fc == null) { > this.channel = fc = FileChannelImpl.open(...); > : > } > } > } > return fc; I was using the form suggested in this article http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html just before the references. Modified. > A minor comment but you can drop the initializing of channel to null (to avoid a needless volatile write). Modified. > In close then you can eliminate a volatile-read with FileChannel fc = channel; if (fc != null) fc.close(); Modified. > In the test then it would be good to assert !fc.isOpen(); Added. > The tryLock is still a bit odd, That was originally to test the change in FileKey.create(). While this change is not strictly necessary I think it is appropriate. > shouldn't that be checking for ClosedChannelException too? Modified. > An alternative name for the test is GetClosedChannel if you are looking for another name. Name changed. Here?s an updated patch: http://cr.openjdk.java.net/~bpb/8025619/webrev.03/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Dec 10 08:18:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Dec 2014 08:18:11 +0000 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: <9B02C8B6-61A1-4FBD-B0DD-361EA4F3CCD5@oracle.com> References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> <547D7F7D.5010505@oracle.com> <9D640615-7CFA-46E6-BC97-C87527B8EA44@oracle.com> <5482ECB0.9050309@oracle.com> <5486AF78.30601@oracle.com> <9B02C8B6-61A1-4FBD-B0DD-361EA4F3CCD5@oracle.com> Message-ID: <548801C3.1040501@oracle.com> On 09/12/2014 20:11, Brian Burkhalter wrote: > > I was using the form suggested in this article > > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html > > > just before the references. Modified. The problem with webrev.02 is that it didn't re-read this.channel and so no guarantee that it wouldn't create more than one FileChannel. I think you have it right now. > : > > Here?s an updated patch: > > http://cr.openjdk.java.net/~bpb/8025619/webrev.03/ > > Looks good, and nice to have a 12 year old issue resolved. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Dec 10 12:29:32 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Dec 2014 12:29:32 +0000 Subject: 8066915: (fs) Files.newByteChannel opens directories for cases where subsequent reads may fail Message-ID: <54883CAC.2010007@oracle.com> As per a recent thread, it's currently possible to open a directory for read access but attempts to actually read will fail. As discussed we are missing a fstat to check the file type so that we can fail when creating the channel. The webrev with the changes to fix this are here: http://cr.openjdk.java.net/~alanb/8066915/webrev/ Thanks, Alan. From fgaliegue at gmail.com Wed Dec 10 12:44:29 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Wed, 10 Dec 2014 13:44:29 +0100 Subject: 8066915: (fs) Files.newByteChannel opens directories for cases where subsequent reads may fail In-Reply-To: <54883CAC.2010007@oracle.com> References: <54883CAC.2010007@oracle.com> Message-ID: On Wed, Dec 10, 2014 at 1:29 PM, Alan Bateman wrote: > > As per a recent thread, it's currently possible to open a directory for read > access but attempts to actually read will fail. As discussed we are missing > a fstat to check the file type so that we can fail when creating the > channel. The webrev with the changes to fix this are here: > http://cr.openjdk.java.net/~alanb/8066915/webrev/ > > Thanks, > Alan. Can this possibly be fixed for Windows as well, instead of getting an AccessDeniedException? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Wed Dec 10 13:51:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Dec 2014 13:51:38 +0000 Subject: 8066915: (fs) Files.newByteChannel opens directories for cases where subsequent reads may fail In-Reply-To: References: <54883CAC.2010007@oracle.com> Message-ID: <54884FEA.20802@oracle.com> On 10/12/2014 12:44, Francis Galiegue wrote: > Can this possibly be fixed for Windows as well, instead of getting an > AccessDeniedException? AccessDeniedException (which is an IOException) is confusing, it's just the translation of the "Access Denied" error that we get from Windows. There are a few subtle issues to deal with but I think something is possible. As I noted in the bug, we would prefer to keep this as a separate issue as it requires changes in a different area of the code. -Alan. From chris.hegarty at oracle.com Wed Dec 10 14:16:32 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 10 Dec 2014 14:16:32 +0000 Subject: 8066915: (fs) Files.newByteChannel opens directories for cases where subsequent reads may fail In-Reply-To: <54884FEA.20802@oracle.com> References: <54883CAC.2010007@oracle.com> <54884FEA.20802@oracle.com> Message-ID: <548855C0.8070605@oracle.com> On 10/12/14 13:51, Alan Bateman wrote: > On 10/12/2014 12:44, Francis Galiegue wrote: >> Can this possibly be fixed for Windows as well, instead of getting an >> AccessDeniedException? > AccessDeniedException (which is an IOException) is confusing, it's just > the translation of the "Access Denied" error that we get from Windows. > There are a few subtle issues to deal with but I think something is > possible. As I noted in the bug, we would prefer to keep this as a > separate issue as it requires changes in a different area of the code. This approach make sense to me. I've taken a look a the webrev and the changes look good. -Chris. From brian.burkhalter at oracle.com Wed Dec 10 17:05:13 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Dec 2014 09:05:13 -0800 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: <548801C3.1040501@oracle.com> References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> <5476DE75.6010909@oracle.com> <547D7F7D.5010505@oracle.com> <9D640615-7CFA-46E6-BC97-C87527B8EA44@oracle.com> <5482ECB0.9050309@oracle.com> <5486AF78.30601@oracle.com> <9B02C8B6-61A1-4FBD-B0DD-361EA4F3CCD5@oracle.com> <548801C3.1040501@oracle.com> Message-ID: On Dec 10, 2014, at 12:18 AM, Alan Bateman wrote: > On 09/12/2014 20:11, Brian Burkhalter wrote: >> >> I was using the form suggested in this article >> >> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html >> >> just before the references. Modified. > The problem with webrev.02 is that it didn't re-read this.channel and so no guarantee that it wouldn't create more than one FileChannel. I think you have it right now. I see. >> : >> >> Here?s an updated patch: >> >> http://cr.openjdk.java.net/~bpb/8025619/webrev.03/ >> > Looks good, and nice to have a 12 year old issue resolved. OK, good. I think I?ll do a JPRT run before pushing it however so it might not be today. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Wed Dec 10 19:48:24 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Wed, 10 Dec 2014 20:48:24 +0100 Subject: Bug in Files.copy() where the source Path is a directory... It _is_ a bug, right? Message-ID: Well, at least the behaviour is very counterintuitive. Here is the situation: $ pwd /hope/fge/tmp $ stat -c foo directory $ find foo foo foo/bar $ stat -c %F meh stat: cannot stat ?meh?: No such file or directory OK, so: * foo is a non empty directory; * there is no meh at this place. Now, this is the code: public static void main(final String... args) throws IOException { final Path dir = Paths.get("/home/fge/tmp/foo"); final Path dst = dir.resolveSibling("meh"); Files.copy(dir, dst); } This code DOES NOT FAIL (not even with DirectoryNotEmptyException on the source). And the result is this: $ stat -c %F meh directory $ find meh meh Yep, it only copied the directory entry and no files under it! -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From fgaliegue at gmail.com Wed Dec 10 19:50:24 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Wed, 10 Dec 2014 20:50:24 +0100 Subject: Bug in Files.copy() where the source Path is a directory... It _is_ a bug, right? In-Reply-To: References: Message-ID: On Wed, Dec 10, 2014 at 8:48 PM, Francis Galiegue wrote: [...] > $ stat -c foo That should have been stat -c %F foo. -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Wed Dec 10 21:34:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Dec 2014 21:34:04 +0000 Subject: Bug in Files.copy() where the source Path is a directory... It _is_ a bug, right? In-Reply-To: References: Message-ID: <5488BC4C.9000708@oracle.com> On 10/12/2014 19:48, Francis Galiegue wrote: > : > > Yep, it only copied the directory entry and no files under it! > Here's what the javadoc says: "If the file is a directory then it creates an empty directory in the target location (entries in the directory are not copied). This method can be used with the walkFileTree method to copy a directory and all entries in the directory, or an entire file-tree where required." There have been requests over the years to add support for recursive copy, maybe a copyFileTree method but all suggestions to date didn't get to a consensus on how exceptions should be handled when only a subset of the file tree can be copied. Maybe some day. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Wed Dec 10 22:06:28 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Wed, 10 Dec 2014 23:06:28 +0100 Subject: Bug in Files.copy() where the source Path is a directory... It _is_ a bug, right? In-Reply-To: <5488BC4C.9000708@oracle.com> References: <5488BC4C.9000708@oracle.com> Message-ID: On Wed, Dec 10, 2014 at 10:34 PM, Alan Bateman wrote: > On 10/12/2014 19:48, Francis Galiegue wrote: > > : > > Yep, it only copied the directory entry and no files under it! > > Here's what the javadoc says: > > "If the file is a directory then it creates an empty directory in the target > location (entries in the directory are not copied). This method can be used > with the walkFileTree method to copy a directory and all entries in the > directory, or an entire file-tree where required." > OK, so yet again an example of me only reading parts of the doc... May I suggest that this part of the doc be emphasized? > There have been requests over the years to add support for recursive copy, > maybe a copyFileTree method but all suggestions to date didn't get to a > consensus on how exceptions should be handled when only a subset of the file > tree can be copied. Maybe some day. > Well, I have in the pipe to create a java7-fs-more package where I will create a MoreFiles and MorePaths utility classes with recursive copy/move features, path resolution across different filesystems etc... I will announce it on this list when I have a first version of it. Before I do that however, I am still on some java.nio.file related projects, so I'd appreciate comments on it: * https://github.com/fge/java7-fs-base --> framework to implement new FileSystems, with limitations, of course; not all of them are fully documented; * https://github.com/fge/java7-fs-dropbox --> a FileSystem implementation over DropBox, based on -base; * https://github.com/fge/java7-fs-box --> a FileSystem implementation over box.com, also based on -base. As to other existing java.nio.file FileSystem implmentations, I only know of two: * https://github.com/google/jimfs --> an in-memory FileSystem, by Google; * https://github.com/fge/java7-fs-ftp --> meh, that was my first attempt as a custom FileSystem and prompted me to create -base and others; not yet rebased on -base. In summary, I am very excited with this new API and it is now three years old; as such I am quite surprised that its usage is still scarce as of 2014. Even in the latest JDK, for instance FileInputStream won't accept any Path arguments; a ProcessBuilder won't allow to redirect to a Path, only to a File. Is this on purpose? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From cgdecker at google.com Wed Dec 10 22:06:48 2014 From: cgdecker at google.com (Colin Decker) Date: Wed, 10 Dec 2014 22:06:48 +0000 Subject: Bug in Files.copy() where the source Path is a directory... It _is_ a bug, right? References: <5488BC4C.9000708@oracle.com> Message-ID: On Wed Dec 10 2014 at 4:34:19 PM Alan Bateman wrote: > > There have been requests over the years to add support for recursive copy, > maybe a copyFileTree method but all suggestions to date didn't get to a > consensus on how exceptions should be handled when only a subset of the > file tree can be copied. Maybe some day. > I've implemented a secure (using SecureDirectoryStream) recursive delete; I ended up choosing to attempt to delete all files, throwing a single exception at the end with all the exceptions for individual files that couldn't be deleted. Obviously there are a lot of other things you could choose to do though. On a related note, the fact that SecureDirectoryStream has neither a copy() method nor a method for creating a directory makes me a little sad, as it makes it impossible to implement a recursive copy that has similar security guarantees. > > -Alan > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Dec 11 07:49:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Dec 2014 07:49:09 +0000 Subject: Bug in Files.copy() where the source Path is a directory... It _is_ a bug, right? In-Reply-To: References: <5488BC4C.9000708@oracle.com> Message-ID: <54894C75.4060402@oracle.com> On 10/12/2014 22:06, Francis Galiegue wrote: > : > > As to other existing java.nio.file FileSystem implmentations, I only > know of two: > > * https://github.com/google/jimfs --> an in-memory FileSystem, by Google; > * https://github.com/fge/java7-fs-ftp --> meh, that was my first > attempt as a custom FileSystem and prompted me to create -base and > others; not yet rebased on -base. > > I don't know if anyone is maintaining a catalog anywhere, we usually only hear about custom providers when folks show up here with questions or bug reports. A quick search finds a number of providers, one for Amazon S3 (that I wasn't aware of), ssh, CIFS, and one for ZIP and several other archive formats. I don't know how complete they are of course. In the JDK then we've included the zip provider since JDK 7 and a new one in JDK 9 is the "jrt" file system that is a read-only file system to access the class and resources files in a runtime image (this is what javac and other tools in the JDK now use). In general then creating file system providers has been somewhat of a niche (but fun) area. It would be good to do a survey of what exists, create a catalog and see if there are opportunities to collaborate. -Alan. From mik3hall at gmail.com Thu Dec 11 10:10:48 2014 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 11 Dec 2014 04:10:48 -0600 Subject: Bug in Files.copy() where the source Path is a directory... It _is_ a bug, right? In-Reply-To: <54894C75.4060402@oracle.com> References: <5488BC4C.9000708@oracle.com> <54894C75.4060402@oracle.com> Message-ID: On Dec 11, 2014, at 1:49 AM, Alan Bateman wrote: > On 10/12/2014 22:06, Francis Galiegue wrote: >> : >> >> As to other existing java.nio.file FileSystem implmentations, I only >> know of two: >> >> * https://github.com/google/jimfs --> an in-memory FileSystem, by Google; >> * https://github.com/fge/java7-fs-ftp --> meh, that was my first >> attempt as a custom FileSystem and prompted me to create -base and >> others; not yet rebased on -base. >> >> > I don't know if anyone is maintaining a catalog anywhere, we usually only hear about custom providers when folks show up here with questions or bug reports. > > A quick search finds a number of providers, one for Amazon S3 (that I wasn't aware of), ssh, CIFS, and one for ZIP and several other archive formats. I don't know how complete they are of course. > > In the JDK then we've included the zip provider since JDK 7 and a new one in JDK 9 is the "jrt" file system that is a read-only file system to access the class and resources files in a runtime image (this is what javac and other tools in the JDK now use). > > In general then creating file system providers has been somewhat of a niche (but fun) area. It would be good to do a survey of what exists, create a catalog and see if there are opportunities to collaborate. https://github.com/marschall/memoryfilesystem I think I saw a change roll through that might of been related to this list thread. My own trz? https://github.com/mik3hall/trz Mainly uses FileSystemProvider to expose native OS X file system API?s as nio.2 attributes. Some not really usable attempts at native OS X WatchServices. Not affected by this bug and maybe not a real FileSystem. But if you?re keeping a list. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5262 bytes Desc: not available URL: From Alan.Bateman at oracle.com Thu Dec 11 10:33:24 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Dec 2014 10:33:24 +0000 Subject: Bug in Files.copy() where the source Path is a directory... It _is_ a bug, right? In-Reply-To: References: <5488BC4C.9000708@oracle.com> Message-ID: <548972F4.6020404@oracle.com> On 10/12/2014 22:06, Francis Galiegue wrote: > : > > Even in the latest JDK, for instance FileInputStream won't accept any > Path arguments; a ProcessBuilder won't allow to redirect to a Path, > only to a File. Is this on purpose? > FileInputStream has methods such as getFD and getChannel that might not make sense to anything excepts files in the platform file system. Anything with a Path can easily call Files.newInputStream, assuming what it is doing doesn't require anything more specific than an InputStream. The ProcessBuilder.redirectXXX methods are a case where maybe we should have used Path (sometimes it's hard to make wide spread use of new APIs in the release where they are introduced). However, these methods should likely need to fail when the Path is not associated with the default provider, it would likely not be feasible to redirect process input or output to files in arbitrary file systems without a forwarding mechanism. In general I think it's a bit of a slow burner, in time there will likely be more APIs in the platform using the newer API. -Alan. From Alan.Bateman at oracle.com Thu Dec 11 11:51:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Dec 2014 11:51:08 +0000 Subject: Bug in Files.copy() where the source Path is a directory... It _is_ a bug, right? In-Reply-To: References: <5488BC4C.9000708@oracle.com> Message-ID: <5489852C.9060704@oracle.com> On 10/12/2014 22:06, Colin Decker wrote: > : > > On a related note, the fact that SecureDirectoryStream has neither a > copy() method nor a method for creating a directory makes me a little > sad, as it makes it impossible to implement a recursive copy that has > similar security guarantees. I'd like to see a createDirectory there too, the reason it didn't make it in originally was due to lack of support for mkdirat. I'm not sure how copy would fit here because it wouldn't be an atomic operation. -Alan From fgaliegue at gmail.com Fri Dec 12 14:00:00 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 12 Dec 2014 15:00:00 +0100 Subject: Why doesn't FileSystemProvider#getFileAttributeView() throw an IOException? Message-ID: All other methods to read/write attributes (including the one in Files) do. This one is the only exception. This is all the more strange that you are theoretically supposed to follow symlinks if the relevant link option is passed and your fs supports it, and .toRealPath() _does_ throw an IOException... Overlook? At this moment, it appears that on error there is no other choice than to throw an unchecked exception... Ouch. -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Fri Dec 12 14:35:30 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Dec 2014 14:35:30 +0000 Subject: Why doesn't FileSystemProvider#getFileAttributeView() throw an IOException? In-Reply-To: References: Message-ID: <548AFD32.10903@oracle.com> On 12/12/2014 14:00, Francis Galiegue wrote: > All other methods to read/write attributes (including the one in > Files) do. This one is the only exception. > > This is all the more strange that you are theoretically supposed to > follow symlinks if the relevant link option is passed and your fs > supports it, and .toRealPath() _does_ throw an IOException... > > Overlook? > > At this moment, it appears that on error there is no other choice than > to throw an unchecked exception... Ouch. This method doesn't read/write file attributes. Instead it is specified to return you an object of the given view type that you can use to access the attributes that the view defines. Most applications shouldn't need to work at this level of course (as Files defines methods to do most of the common operations). -Alan From fgaliegue at gmail.com Fri Dec 12 14:42:50 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 12 Dec 2014 15:42:50 +0100 Subject: Why doesn't FileSystemProvider#getFileAttributeView() throw an IOException? In-Reply-To: <548AFD32.10903@oracle.com> References: <548AFD32.10903@oracle.com> Message-ID: On Fri, Dec 12, 2014 at 3:35 PM, Alan Bateman wrote: > On 12/12/2014 14:00, Francis Galiegue wrote: >> >> All other methods to read/write attributes (including the one in >> Files) do. This one is the only exception. >> >> This is all the more strange that you are theoretically supposed to >> follow symlinks if the relevant link option is passed and your fs >> supports it, and .toRealPath() _does_ throw an IOException... >> >> Overlook? >> >> At this moment, it appears that on error there is no other choice than >> to throw an unchecked exception... Ouch. > > > This method doesn't read/write file attributes. Instead it is specified to > return you an object of the given view type that you can use to access the > attributes that the view defines. > Uh, doesn't that pretty much mean that implementations of such views are essentially condemned to do "lazy loading", including the path? > Most applications shouldn't need to work > at this level of course (as Files defines methods to do most of the common > operations). > Well yes, and these method _do_ throw IOExceptions, which is why I find it really strange that this one does not. While the explanation kind of makes sense, implementing it is, uh. -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From cgdecker at google.com Fri Dec 12 17:37:31 2014 From: cgdecker at google.com (Colin Decker) Date: Fri, 12 Dec 2014 17:37:31 +0000 Subject: Why doesn't FileSystemProvider#getFileAttributeView() throw an IOException? References: <548AFD32.10903@oracle.com> Message-ID: Implementing the file attribute stuff (in a generalized way, anyway) is somewhat of a pain, but implementing views didn't seem like a particularly hard part of that to me. You just need to look up the file for each operation on the view. I handled that by having views wrap a FileLookup object rather than a handle to an open file. Not saying that's exactly how it should work in all cases or anything, of course. On Fri Dec 12 2014 at 9:43:58 AM Francis Galiegue wrote: > On Fri, Dec 12, 2014 at 3:35 PM, Alan Bateman > wrote: > > On 12/12/2014 14:00, Francis Galiegue wrote: > >> > >> All other methods to read/write attributes (including the one in > >> Files) do. This one is the only exception. > >> > >> This is all the more strange that you are theoretically supposed to > >> follow symlinks if the relevant link option is passed and your fs > >> supports it, and .toRealPath() _does_ throw an IOException... > >> > >> Overlook? > >> > >> At this moment, it appears that on error there is no other choice than > >> to throw an unchecked exception... Ouch. > > > > > > This method doesn't read/write file attributes. Instead it is specified > to > > return you an object of the given view type that you can use to access > the > > attributes that the view defines. > > > > Uh, doesn't that pretty much mean that implementations of such views > are essentially condemned to do "lazy loading", including the path? > > > Most applications shouldn't need to work > > at this level of course (as Files defines methods to do most of the > common > > operations). > > > > Well yes, and these method _do_ throw IOExceptions, which is why I > find it really strange that this one does not. > > While the explanation kind of makes sense, implementing it is, uh. > > -- > Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge > JSON Schema in Java: http://json-schema-validator.herokuapp.com > Parsers in pure Java: https://github.com/parboiled1/grappa (redde > Caesaris: https://github.com/sirthias) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Fri Dec 12 17:45:56 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 12 Dec 2014 18:45:56 +0100 Subject: Why doesn't FileSystemProvider#getFileAttributeView() throw an IOException? In-Reply-To: References: <548AFD32.10903@oracle.com> Message-ID: On Fri, Dec 12, 2014 at 6:37 PM, Colin Decker wrote: > Implementing the file attribute stuff (in a generalized way, anyway) is > somewhat of a pain, but implementing views didn't seem like a particularly > hard part of that to me. You just need to look up the file for each > operation on the view. I handled that by having views wrap a FileLookup > object rather than a handle to an open file. Not saying that's exactly how > it should work in all cases or anything, of course. > > Well, I did have a go at a generalized implementation: https://github.com/fge/java7-fs-base/tree/master/src/main/java/com/github/fge/filesystem/attributes I have yet to document all this API, but I'm eating my own dog's food and already implemented one (crude) file system over dropbox and I'm on to the next now. When this API is documented I'll share the link; I would love reviews, of course! -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Sat Dec 13 10:34:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 13 Dec 2014 10:34:10 +0000 Subject: Why doesn't FileSystemProvider#getFileAttributeView() throw an IOException? In-Reply-To: References: <548AFD32.10903@oracle.com> Message-ID: <548C1622.3040002@oracle.com> On 12/12/2014 17:37, Colin Decker wrote: > Implementing the file attribute stuff (in a generalized way, anyway) > is somewhat of a pain, but implementing views didn't seem like a > particularly hard part of that to me. You just need to look up the > file for each operation on the view. I handled that by having views > wrap a FileLookup > object > rather than a handle to an open file. Not saying that's exactly how it > should work in all cases or anything, of course. That sounds right as there is no requirement for the file to exist at the time that the view is created. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Tue Dec 16 22:36:44 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Tue, 16 Dec 2014 23:36:44 +0100 Subject: Announce: JSR 202 resources, call for contributions/help Message-ID: Hello, I am, myself, a convinced user of java.nio.file; in new code, when I can "afford" Java 7+, File is dead, it is as simple as that. However, nowadays JSR 202 is more than 3 years old, yet it is underused; for instance, I am a heavy Stack Overflow user, and even today, most I/O questions relating to file I/O still use java.io.File. Even when users asking these questions have the possibility to use java.nio.file. Given the huge leap forwards that this new API provides, I cannot even begin to explain this lack of awareness; but that bugs me. Therefore I decided to try and promote JSR 202 in my own way, with two goals in mind: * teach end users about JSR 202; * ease the entry into the JSR 202 API for developers. For the first part, I created a dedicated web site (WARNING: ad-heavy; if you have an ad blocker, use it): https://java7fs.wikia.com For the second part, I created a base project which I am currently actively developping to ease the creation of new filesystems: https://github.com/fge/java7-fs-base In fact, I am that much into developing it at the moment that it is not very accurately documented; still, it troubles me that for instance the JDK defines AbstractPath and others but they are all package private and therefore inaccessible. But from this API I already developed two spawns: * https://github.com/fge/java7-fs-box: a FileSystem over box.com storage services; * https://github.com/fge/java7-fs-dropbox: a FileSystem over dropbox storage services. And I also have this: https://github.com/java7-fs-more; its goal is to provide path resolution methods, recursive copy/deletion methods etc, making it even easier to use the new API. Yes, all of this is in a somewhat crude state; this is early times, nevertheless I'd appreciate feedback. I intend to keep eating my own dog's food, in that I will develop more filesystems using java7-fs-base, happily receive even negative comments about what I have published etc. Regards, -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From brian.burkhalter at oracle.com Tue Dec 16 22:41:58 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Dec 2014 14:41:58 -0800 Subject: RFR 9: 8030090: (fs) Add default methods to Path for derived methods Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8030090 Patch: http://cr.openjdk.java.net/~bpb/8030090/webrev.00/ Summary: Add method implementations from sun.nio.fs.AbstractPath to Path as default implementations. All pertinent core tests pass in JPRT. A CCC request might also be in order? Thanks, Brian From Alan.Bateman at oracle.com Wed Dec 17 08:51:05 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Dec 2014 08:51:05 +0000 Subject: RFR 9: 8030090: (fs) Add default methods to Path for derived methods In-Reply-To: References: Message-ID: <549143F9.8020307@oracle.com> On 16/12/2014 22:41, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8030090 > Patch: http://cr.openjdk.java.net/~bpb/8030090/webrev.00/ This mostly looks good to me although I assumed that sun.nio.fs.AbstractPath would be removed. Is there any reason to keep it? In the toFile() method then it should use == rather than equals as FileSystems.getDefault() returns the singleton that is the default provider. The UOE line is a bit long, might be best to try to get the line lengths consistent if you can. In resolveSibling then a comma after "{@code other == null}" would make it read a bit better. In the iterator method then I wonder if the @implSpec should be reduced down to a statement to specify that it just returns an Iterator to iterate over elements 0 to getNameCount()-1. One thing for the default implementation is that we don't need remove. Formatting nit at L779-L780, you could move the @throws to the previous line or put the { on the next line. A general comment is that you could use "this path" rather than "this {@code Path}" in each of the @implNotes if that looks better. -Alan. From Alan.Bateman at oracle.com Wed Dec 17 09:04:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Dec 2014 09:04:31 +0000 Subject: Announce: JSR 202 resources, call for contributions/help In-Reply-To: References: Message-ID: <5491471F.4000600@oracle.com> On 16/12/2014 22:36, Francis Galiegue wrote: > Hello, > > I am, myself, a convinced user of java.nio.file; in new code, when I > can "afford" Java 7+, File is dead, it is as simple as that. One thing to say on this is that we deliberately did not deprecate java.io.File. It has lots of unfixable issues but it wasn't toxic enough to be deprecated. Instead we focused on making it easy for File and the new API to be used together and allow code migrate over time. Also you'll see that the File javadoc has several references to the new API, the motive being to point readers as methods that will often do the right thing. I have not looked at usage in some time but initially the challenge was libraries and applications that were targeting >= JDK 6 and so could not use the new API. Thanks for your efforts to promote the API. > : > > And I also have this: https://github.com/java7-fs-more; its goal is to > provide path resolution methods, recursive copy/deletion methods etc, > making it even easier to use the new API. > > I get a 404 for this link but I would be interested in your experiences or feedback you get on these. We've prototyped providing recursive versions of the common operations several times but never came to a conclusion on the best way to deal with errors (too many approaches). If you are interested then the samples that ship with the JDK include several that do recursive operations. In sample/nio/file/Copy.java then you'll find a tool that is roughly cp [-R -p -i]. Another one is Chmod.java that is roughly chmod [-R]. In both cases then the error handling roughly matches the equivalent command line tool. -Alan. From mik3hall at gmail.com Wed Dec 17 10:07:16 2014 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 17 Dec 2014 04:07:16 -0600 Subject: Announce: JSR 202 resources, call for contributions/help In-Reply-To: <5491471F.4000600@oracle.com> References: <5491471F.4000600@oracle.com> Message-ID: <3E6447AA-1E13-4BBB-A9F7-4A784E30E741@gmail.com> On Dec 17, 2014, at 3:04 AM, Alan Bateman wrote: > On 16/12/2014 22:36, Francis Galiegue wrote: >> Hello, >> >> I am, myself, a convinced user of java.nio.file; in new code, when I >> can "afford" Java 7+, File is dead, it is as simple as that. > One thing to say on this is that we deliberately did not deprecate java.io.File. It has lots of unfixable issues but it wasn't toxic enough to be deprecated. Instead we focused on making it easy for File and the new API to be used together and allow code migrate over time. Also you'll see that the File javadoc has several references to the new API, the motive being to point readers as methods that will often do the right thing. > > I have not looked at usage in some time but initially the challenge was libraries and applications that were targeting >= JDK 6 and so could not use the new API. > > Thanks for your efforts to promote the API. Wouldn?t deprecating File be sort of like just making a further statement that it isn?t good? As Francis pointed out at this point many people still tend to use it a lot. From the past when it was the only choice there are how many millions and millions of lines of code that include it? Somehow bridging File to allow it at least the possibility to use the new API?s still seems like it would make sense to me. Can you deprecate use? Say that ?we are giving you this usable with File but really you?d be better off using nio?. If you could do that in some way without code needing to change it seems to me it would be the best way to handle this. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5262 bytes Desc: not available URL: From fgaliegue at gmail.com Wed Dec 17 10:43:09 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Wed, 17 Dec 2014 11:43:09 +0100 Subject: Announce: JSR 202 resources, call for contributions/help In-Reply-To: <5491471F.4000600@oracle.com> References: <5491471F.4000600@oracle.com> Message-ID: Hello, On Wed, Dec 17, 2014 at 10:04 AM, Alan Bateman wrote: [...] >> >> And I also have this: https://github.com/java7-fs-more; its goal is to >> provide path resolution methods, recursive copy/deletion methods etc, >> making it even easier to use the new API. >> >> > I get a 404 for this link > Sorry for that... That would be https://github.com/fge/java7-fs-more. Since I am also working on implementing filesystems at the same time this one sees slow progress for now; but basically the plan for deletion is to have two modes: fail fast or "try hard". The first would fail when removing an entry fails, the second would do like rm -rf, basically, and try and remove as much as it can -- and provide the user with a report of what has failed and why. > but I would be interested in your experiences or > feedback you get on these. We've prototyped providing recursive versions of > the common operations several times but never came to a conclusion on the > best way to deal with errors (too many approaches). > > If you are interested then the samples that ship with the JDK include > several that do recursive operations. In sample/nio/file/Copy.java then > you'll find a tool that is roughly cp [-R -p -i]. Another one is Chmod.java > that is roughly chmod [-R]. In both cases then the error handling roughly > matches the equivalent command line tool. > I will! Thank you for the pointers, -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From martijnverburg at gmail.com Wed Dec 17 12:36:43 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 17 Dec 2014 12:36:43 +0000 Subject: Announce: JSR 202 resources, call for contributions/help In-Reply-To: References: <5491471F.4000600@oracle.com> Message-ID: Hi Francis, You maybe interested in hosting the project under the AdoptOpenJDK group in GitHub. The Adoption Group within OpenJDK promotes this sort of thing globally through it's outreach programme (we have tutorials on Lambdas, Date and Time and other modern Java features). You'll likely find extra volunteers to help out as well :-). Let me know! Cheers, Martijn On 17 December 2014 at 10:43, Francis Galiegue wrote: > > Hello, > > On Wed, Dec 17, 2014 at 10:04 AM, Alan Bateman > wrote: > [...] > >> > >> And I also have this: https://github.com/java7-fs-more; its goal is to > >> provide path resolution methods, recursive copy/deletion methods etc, > >> making it even easier to use the new API. > >> > >> > > I get a 404 for this link > > > > Sorry for that... That would be https://github.com/fge/java7-fs-more. > > Since I am also working on implementing filesystems at the same time > this one sees slow progress for now; but basically the plan for > deletion is to have two modes: fail fast or "try hard". The first > would fail when removing an entry fails, the second would do like rm > -rf, basically, and try and remove as much as it can -- and provide > the user with a report of what has failed and why. > > > but I would be interested in your experiences or > > feedback you get on these. We've prototyped providing recursive versions > of > > the common operations several times but never came to a conclusion on the > > best way to deal with errors (too many approaches). > > > > If you are interested then the samples that ship with the JDK include > > several that do recursive operations. In sample/nio/file/Copy.java then > > you'll find a tool that is roughly cp [-R -p -i]. Another one is > Chmod.java > > that is roughly chmod [-R]. In both cases then the error handling roughly > > matches the equivalent command line tool. > > > > I will! Thank you for the pointers, > -- > Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge > JSON Schema in Java: http://json-schema-validator.herokuapp.com > Parsers in pure Java: https://github.com/parboiled1/grappa (redde > Caesaris: https://github.com/sirthias) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Dec 17 17:55:04 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Dec 2014 09:55:04 -0800 Subject: RFR 9: 8030090: (fs) Add default methods to Path for derived methods In-Reply-To: <549143F9.8020307@oracle.com> References: <549143F9.8020307@oracle.com> Message-ID: <17D05ED4-F3FA-4B48-8234-ED893521C65F@oracle.com> On Dec 17, 2014, at 12:51 AM, Alan Bateman wrote: > This mostly looks good to me although I assumed that sun.nio.fs.AbstractPath would be removed. Is there any reason to keep it? I expect I incorrectly interpreted this comment from the issue description: "The only one that needs adjustment is toFile() as it should only return a File if the Path is associated with the default file system. ? > In the toFile() method then it should use == rather than equals as FileSystems.getDefault() returns the singleton that is the default provider. I was wondering about that. > The UOE line is a bit long, might be best to try to get the line lengths consistent if you can. > > In resolveSibling then a comma after "{@code other == null}" would make it read a bit better. > > In the iterator method then I wonder if the @implSpec should be reduced down to a statement to specify that it just returns an Iterator to iterate over elements 0 to getNameCount()-1. The current @implSpec was arrived at after a few iterations on the verbiage. I can pare it down to this however which seems reasonable. > One thing for the default implementation is that we don't need remove. Good point: I forgot to check that it?s a default now in Iterator. > Formatting nit at L779-L780, you could move the @throws to the previous line or put the { on the next line. > > A general comment is that you could use "this path" rather than "this {@code Path}" in each of the @implNotes if that looks better. I?ll make some changes and re-post for review. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Dec 18 00:09:09 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Dec 2014 16:09:09 -0800 Subject: RFR 9: 8030090: (fs) Add default methods to Path for derived methods In-Reply-To: <17D05ED4-F3FA-4B48-8234-ED893521C65F@oracle.com> References: <549143F9.8020307@oracle.com> <17D05ED4-F3FA-4B48-8234-ED893521C65F@oracle.com> Message-ID: <2737BA05-E2E5-4135-8F9D-B1409275585E@oracle.com> On Dec 17, 2014, at 9:55 AM, Brian Burkhalter wrote: > I?ll make some changes and re-post for review. Here?s an updated version: http://cr.openjdk.java.net/~bpb/8030090/webrev.01/ AbstractPath is removed in this case and the other suggested changes put in place. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Thu Dec 18 06:08:04 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Thu, 18 Dec 2014 07:08:04 +0100 Subject: Feedback please? MorePaths.resolve() Message-ID: Some of you may remind the discussion I had with Mr Bateman about filesystem issues when resolving paths (that is, which filesystem the result will belong to). Actually, the resulting paths between the two resolve() methods (the one taking a String as an argument and the one taking a Path as an argument) may not be equal because they don't have the same filesystem (the string version will always return a path which belongs to the caller's filesystem; not the path version). And what is more, even if both paths share the same path structure, if they are from a different provider you cannot resolve (ProviderMismatchException). Since it can be practical to resolve paths against one another even if they are issued from different providers, and in order to ensure that they are both on the same filesystem, I wrote such a method: https://gist.github.com/fge/34e93d9dca4f56c27d16 Comments? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Thu Dec 18 11:33:47 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Dec 2014 11:33:47 +0000 Subject: RFR 9: 8030090: (fs) Add default methods to Path for derived methods In-Reply-To: <2737BA05-E2E5-4135-8F9D-B1409275585E@oracle.com> References: <549143F9.8020307@oracle.com> <17D05ED4-F3FA-4B48-8234-ED893521C65F@oracle.com> <2737BA05-E2E5-4135-8F9D-B1409275585E@oracle.com> Message-ID: <5492BB9B.3070405@oracle.com> On 18/12/2014 00:09, Brian Burkhalter wrote: > > On Dec 17, 2014, at 9:55 AM, Brian Burkhalter > > wrote: > >> I?ll make some changes and re-post for review. > > Here?s an updated version: > > http://cr.openjdk.java.net/~bpb/8030090/webrev.01/ > > > AbstractPath is removed in this case and the other suggested changes > put in place. > Thanks, this looks quite good. For toFile() then it looks like some of text from your first version (after the ) has been removed and that is needed to have it be complete. Minor formatting nit in UnixPath is that you the "{" can be moved up to the previous line. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Thu Dec 18 15:08:27 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Thu, 18 Dec 2014 16:08:27 +0100 Subject: Question about FileSystem's .supportedFileAttributeViews() Message-ID: The documentation is not very clear about this, but let's say, for instance, that an implementation supports the "acl" view; is it required that this method report also "owner", since acl "inherits" owner, so to speak? Similarly, if it supports "posix", will it have to also report "basic" and "owner"? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From brian.burkhalter at oracle.com Thu Dec 18 16:18:40 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Dec 2014 08:18:40 -0800 Subject: RFR 9: 8030090: (fs) Add default methods to Path for derived methods In-Reply-To: <5492BB9B.3070405@oracle.com> References: <549143F9.8020307@oracle.com> <17D05ED4-F3FA-4B48-8234-ED893521C65F@oracle.com> <2737BA05-E2E5-4135-8F9D-B1409275585E@oracle.com> <5492BB9B.3070405@oracle.com> Message-ID: <9CD82B89-DD0D-42AF-9D73-A16B394A29A2@oracle.com> On Dec 18, 2014, at 3:33 AM, Alan Bateman wrote: > Thanks, this looks quite good. > > For toFile() then it looks like some of text from your first version (after the ) has been removed and that is needed to have it be complete. I took that out because I thought the throws documentation covered it: UnsupportedOperationException - if this Path is not associated with the default provider [1] It does not hurt however to elaborate. > Minor formatting nit in UnixPath is that you the "{" can be moved up to the previous line. Please see this updated version which incorporates the two foregoing changes: http://cr.openjdk.java.net/~bpb/8030090/webrev.02/ Thanks, Brian [1] http://docs.oracle.com/javase/8/docs/api/java/nio/file/Path.html#toFile-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Dec 18 18:15:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Dec 2014 18:15:26 +0000 Subject: Question about FileSystem's .supportedFileAttributeViews() In-Reply-To: References: Message-ID: <549319BE.4000402@oracle.com> On 18/12/2014 15:08, Francis Galiegue wrote: > The documentation is not very clear about this, but let's say, for > instance, that an implementation supports the "acl" view; is it > required that this method report also "owner", since acl "inherits" > owner, so to speak? Similarly, if it supports "posix", will it have to > also report "basic" and "owner"? > All implementations are required to support basic. There isn't any requirement to support other views beyond that. Also no requirement to support "owner" if you support posix or acl. Clearly if you support either of those then it should be trivial to support owner too. -Alan From Alan.Bateman at oracle.com Thu Dec 18 18:17:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Dec 2014 18:17:54 +0000 Subject: RFR 9: 8030090: (fs) Add default methods to Path for derived methods In-Reply-To: <9CD82B89-DD0D-42AF-9D73-A16B394A29A2@oracle.com> References: <549143F9.8020307@oracle.com> <17D05ED4-F3FA-4B48-8234-ED893521C65F@oracle.com> <2737BA05-E2E5-4135-8F9D-B1409275585E@oracle.com> <5492BB9B.3070405@oracle.com> <9CD82B89-DD0D-42AF-9D73-A16B394A29A2@oracle.com> Message-ID: <54931A52.4030202@oracle.com> On 18/12/2014 16:18, Brian Burkhalter wrote: > > > Please see this updated version which incorporates the two foregoing > changes: > > http://cr.openjdk.java.net/~bpb/8030090/webrev.02/ > > Looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Thu Dec 18 18:27:03 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Thu, 18 Dec 2014 19:27:03 +0100 Subject: Question about FileSystem's .supportedFileAttributeViews() In-Reply-To: <549319BE.4000402@oracle.com> References: <549319BE.4000402@oracle.com> Message-ID: On Thu, Dec 18, 2014 at 7:15 PM, Alan Bateman wrote: > On 18/12/2014 15:08, Francis Galiegue wrote: >> >> The documentation is not very clear about this, but let's say, for >> instance, that an implementation supports the "acl" view; is it >> required that this method report also "owner", since acl "inherits" >> owner, so to speak? Similarly, if it supports "posix", will it have to >> also report "basic" and "owner"? >> > All implementations are required to support basic. > Yep, I know ;) > There isn't any requirement to support other views beyond that. Also no > requirement to support "owner" if you support posix or acl. Clearly if you > support either of those then it should be trivial to support owner too. > OK, I just wanted to know. This is because in my helper library, when you implement posix for instance, you automatically support owner and basic. This allows an fs developer to not care about such "trivial" matters ;) The "load on demand" bug still isn't cured, though... Thanks, -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From fgaliegue at gmail.com Sat Dec 20 09:55:50 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 20 Dec 2014 10:55:50 +0100 Subject: Files.createFile() does not ignore umask on Unix systems, is this expected? Message-ID: Consider the following test program (imports omitted for brevity): ---- public class Test { public static void main(final String... args) throws IOException { final Path toCreate = Paths.get("testdir"); Files.deleteIfExists(toCreate); final Set perms = PosixFilePermissions.fromString("rw-rw-rw-"); final FileAttribute attr = PosixFilePermissions.asFileAttribute(perms); final Path created = Files.createFile(toCreate, attr); final Set actualPerms = Files.getPosixFilePermissions(created); System.out.println(PosixFilePermissions.toString(actualPerms)); System.exit(0); } } ---- Now, when running this, I get the following results: ---- fge at alustriel:/tmp$ umask 0027 fge at alustriel:/tmp$ javac -version; java -version javac 1.8.0_25 java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) fge at alustriel:/tmp$ javac Test.java fge at alustriel:/tmp$ java Test rw-r----- fge at alustriel:/tmp$ source ~/.jdk/7;javac -version; java -version javac 1.7.0_72 java version "1.7.0_72" Java(TM) SE Runtime Environment (build 1.7.0_72-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode) fge at alustriel:/tmp$ javac Test.java fge at alustriel:/tmp$ java Test rw-r----- ---- Which means that despite my specifying a 666 mode for creation, the umask did apply. I'd have expected it not to... The documentation does not say anything about this particular scenario, but it this the intended behaviour? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From fgaliegue at gmail.com Sat Dec 20 10:17:29 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 20 Dec 2014 11:17:29 +0100 Subject: Files.createFile() does not ignore umask on Unix systems, is this expected? In-Reply-To: References: Message-ID: On Sat, Dec 20, 2014 at 10:55 AM, Francis Galiegue wrote: [...] > > Which means that despite my specifying a 666 mode for creation, the > umask did apply. I'd have expected it not to... > > The documentation does not say anything about this particular > scenario, but it this the intended behaviour? > Well it appears that it is; this is the intended behaviour if open(2) specifies O_CREAT according to its manpage, so nothing surprising, I guess. -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From weijun.wang at oracle.com Mon Dec 22 10:18:23 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Dec 2014 18:18:23 +0800 Subject: Path of "." and "" In-Reply-To: <5485874D.2020908@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> <5485874D.2020908@oracle.com> Message-ID: <5497EFEF.4040807@oracle.com> On 12/8/2014 19:11, Alan Bateman wrote: > On 08/12/2014 10:55, Wang Weijun wrote: >>> : >>> >>> I am just complaining it's not intuitive that an empty Path does not simply have zero name element. > The long standing issue with the empty path is just trying to keep > things consistent. Can you give some example? What problem will it make? --Max From fgaliegue at gmail.com Mon Dec 22 12:52:04 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 22 Dec 2014 13:52:04 +0100 Subject: Path of "." and "" In-Reply-To: <5497EFEF.4040807@oracle.com> References: <2B6A5946-8FB5-4C1C-BC4B-BB987E84815D@oracle.com> <548576D8.60400@oracle.com> <3E3C2C93-6F2B-410B-BBBD-04AD5937E94C@oracle.com> <5485874D.2020908@oracle.com> <5497EFEF.4040807@oracle.com> Message-ID: On Mon, Dec 22, 2014 at 11:18 AM, Weijun Wang wrote: [...] >>>> >>>> I am just complaining it's not intuitive that an empty Path does not >>>> simply have zero name element. >> >> The long standing issue with the empty path is just trying to keep >> things consistent. > > > Can you give some example? What problem will it make? > Well, have you tried implementing Path? ;) Honestly, that requirement makes things more complicated than what they need to be (and Path is already hard enough, what with no base abstract classes directly usable). My generic (final!) implementation does not obey this requirement (empty means empty), and I am only saved by the fact that trying and manipulating paths from different providers together throws a ProviderMismatchException... -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From weijun.wang at oracle.com Mon Dec 22 14:23:03 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Dec 2014 22:23:03 +0800 Subject: [nio-path] Is there a connection between "C:\" and "C:"? Message-ID: <54982947.6060102@oracle.com> These 2 are all root paths, but is there any API that shows a connection between them? I don't want to consult the actual file system (i.e. calling toRealPath() or toAbsolutePath()). Thanks Max From fgaliegue at gmail.com Tue Dec 23 11:21:43 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Tue, 23 Dec 2014 12:21:43 +0100 Subject: Announce: java7-fs-more 0.1.0 Message-ID: Hello, Project home: https://github.com/fge/java7-fs-more. Javadoc: https://fge.github.io/java7-fs-more. This project aims at providing utility methods to complement the JDK's Files class mostly and also a few Path related utility method. In particular: * recursive copy/deletion (move not implemented yet); * cross-filesystem path resolution; * shortcuts to set Unix file permissions (I'm a Unix guy...). It is, of course, a work in progress and it's only the first version; nevertheless I am looking for feedback. I do believe it to be useful enough already that you can use it for your own needs! It is quite heavily tested; for this I make use of memoryfilesystem and jimfs, which are two in-memory filesystems with many features: * memoryfilesystem: https://github.com/marschall/memoryfilesystem * jimfs: https://github.com/google/jimfs The documentation is only partially complete, I am aware of it; if you wish to, please report any inaccuracies/misunderstandings as issues on the project, not this list! Thank you for reading, and a merry Christmas and happy new year to all, -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Sun Dec 28 13:01:18 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Dec 2014 13:01:18 +0000 Subject: Files.createFile() does not ignore umask on Unix systems, is this expected? In-Reply-To: References: Message-ID: <549FFF1E.2090004@oracle.com> On 20/12/2014 09:55, Francis Galiegue wrote: > : > > Which means that despite my specifying a 666 mode for creation, the > umask did apply. I'd have expected it not to... > > The documentation does not say anything about this particular > scenario, but it this the intended behaviour? > The javadoc in PosixFileAttributeView has a section entitled "Setting Initial Permissions" on this topic. -Alan. From Alan.Bateman at oracle.com Mon Dec 29 08:32:30 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Dec 2014 08:32:30 +0000 Subject: [nio-path] Is there a connection between "C:\" and "C:"? In-Reply-To: <54982947.6060102@oracle.com> References: <54982947.6060102@oracle.com> Message-ID: <54A1119E.6030605@oracle.com> On 22/12/2014 14:23, Weijun Wang wrote: > These 2 are all root paths, but is there any API that shows a > connection between them? > > I don't want to consult the actual file system (i.e. calling > toRealPath() or toAbsolutePath()). I think more context is needed to understand what you mean by "shows a connection". Clearly you can use toRealPath and check if they are equal, or you could use Files.getFileStore and check if both paths are to directories on the same FileStore. However in both cases you will need to access the file system. -Alan From weijun.wang at oracle.com Tue Dec 30 04:01:52 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Dec 2014 12:01:52 +0800 Subject: [fs] Accept Paths.get("/c:/x") on Windows? Message-ID: <54A223B0.2070109@oracle.com> new File("/c:/x") return c:\x, but Paths.get() throws an exception java.nio.file.InvalidPathException: Illegal char <:> at index 2: /c:/x at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94) at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255) at java.nio.file.Paths.get(Paths.java:84) Is this something that can be fixed? I am asking this because FileURLConnection.getPermission() uses url.getPath() as a file name, and the url was like file:/c:/x. Thanks Max From Alan.Bateman at oracle.com Tue Dec 30 08:00:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Dec 2014 08:00:48 +0000 Subject: [fs] Accept Paths.get("/c:/x") on Windows? In-Reply-To: <54A223B0.2070109@oracle.com> References: <54A223B0.2070109@oracle.com> Message-ID: <54A25BB0.50409@oracle.com> On 30/12/2014 04:01, Weijun Wang wrote: > new File("/c:/x") return c:\x, but Paths.get() throws an exception > > java.nio.file.InvalidPathException: Illegal char <:> at index 2: /c:/x > at > sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94) > at > sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255) > at java.nio.file.Paths.get(Paths.java:84) > > Is this something that can be fixed? > > I am asking this because FileURLConnection.getPermission() uses > url.getPath() as a file name, and the url was like file:/c:/x. InvalidPathException looks correct as the file path is malformed. In general then you can't use a URL path as file path. I don't have time to check now but I think there are a couple of hacks in File and the file protocol handler on this issue, there might be an opportunity to do some clean-up. -Alan From weijun.wang at oracle.com Tue Dec 30 14:01:13 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 30 Dec 2014 22:01:13 +0800 Subject: [fs] Accept Paths.get("/c:/x") on Windows? In-Reply-To: <54A25BB0.50409@oracle.com> References: <54A223B0.2070109@oracle.com> <54A25BB0.50409@oracle.com> Message-ID: <361DC233-7182-4BA2-9CC1-CAF259D5ED28@oracle.com> > On Dec 30, 2014, at 16:00, Alan Bateman wrote: > > On 30/12/2014 04:01, Weijun Wang wrote: >> new File("/c:/x") return c:\x, but Paths.get() throws an exception >> >> java.nio.file.InvalidPathException: Illegal char <:> at index 2: /c:/x >> at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) >> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) >> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) >> at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94) >> at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255) >> at java.nio.file.Paths.get(Paths.java:84) >> >> Is this something that can be fixed? >> >> I am asking this because FileURLConnection.getPermission() uses url.getPath() as a file name, and the url was like file:/c:/x. > InvalidPathException looks correct as the file path is malformed. > > In general then you can't use a URL path as file path. Is Paths.get(url.toURI()) designed for this? --Max From ivan.gerasimov at oracle.com Tue Dec 30 14:33:04 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 30 Dec 2014 17:33:04 +0300 Subject: RFR: 8068384: Memleak in WinNTFileSystem_md.c Message-ID: <54A2B7A0.2010100@oracle.com> Hello! There appears to be a memory leak in WinNTFileSystem_list() function. I should have noticed it when doing cleanup with JDK-8056310, but missed it somehow. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068384 WEBREV: http://cr.openjdk.java.net/~igerasim/8068384/0/webrev/ Sincerely yours, Ivan