From littlee at linux.vnet.ibm.com Wed Jan 4 00:10:18 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Wed, 04 Jan 2012 16:10:18 +0800
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4EFDD874.6070608@oracle.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
Message-ID: <4F04096A.2010404@linux.vnet.ibm.com>
Hi Alan,
On 12/30/2011 11:27 PM, Alan Bateman wrote:
> On 29/12/2011 03:27, Charles Lee wrote:
>>
>> Hi Alan,
>>
>> I have the same concern. So I did a grep on "LinkOption" and found
>> that the Usage of O_NOFOLLOW fell into two categories:
>> 1. used to make a value to a boolean: flags.followLinks,
>> Util.followLinks. In this situation give O_NOFOLLOW to 0 will do no
>> harm.
>> 2. pass a part of flags to the native directly: open and openat in
>> the UnixChannelFactory, UnixPath and UnixSecureDirectoryStream. In
>> this situation, maybe we should throw UnsupportedOperationException?
>>
>> What do you think if I use 0 as a flag to O_NOFOLLOW is not supported?
>>
> I'll send mail when I get back next week but off-hand:
>
> 1. SecureDirectoryStream can't be supported on platforms that don't
> have O_NOFOLLOW so it means that
> UnixFileSystemProvider.newDirectoryStream will require to check this
> before deciding the type of DirectoryStream to return.
I agree with you. Just simply changing the code in the
NativeDispatcher's init method will make it happen.
>
> 2. UnixChannelFactory (which is used by
> UnixFileSystemProvider.newFileChannel and newAsynchronousFileChannel)
> will need to fail with UOE if NOFOLLOW_LINKS is specified as an option
> when opening a file. It's not one of the standard opens and so it's
> required to be supported, it just happens that all the platforms we
> currently
This part of code is a bit tricky. Because !CREATE_NEW &&
DELETE_ON_CLOSE will still need O_NOFOLLOW. It will be strange for user
if they do not know the details of implementation but get "Unsupported
no follow option" only because they use !CREATE_NEW && DELETE_ON_CLOSE.
Can I remove the !CREATE_NEW && DELETE_ON_CLOSE ?
>
> 3. Where a FileAttributeView is created that doesn't follow sym links
> then it's highly platform specific if it can be used to update the
> attributes of the sym link. This is where
> UnixPath.openForAttributeAccess is used. I need to double check the
> javadoc to see how this is specified as I can't recall off-hand if
> this is treated as an UOE or an IOException (I think the latter).
>
From the code and doc, I guess it throws IOException. It is interesting
that methods in the FileSystemProvider throw UOE because not supporting
specific attribute view, not include not supporting options. Can we add
this in the doc? I'd like a UOE been throw in the FileSystemProvider if
a method is provided a NOFOLLOW_LINKS on the platform which is not
supported O_NOFOLLOW. This will include all the methods which has option
as its parameter in the FileSystemProvider. What do you think, Alan?
> -Alan.
>
--
Yours Charles
From Alan.Bateman at oracle.com Wed Jan 4 04:34:16 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Jan 2012 12:34:16 +0000
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F04096A.2010404@linux.vnet.ibm.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com>
Message-ID: <4F044748.8010706@oracle.com>
On 04/01/2012 08:10, Charles Lee wrote:
> :
>>
>> 1. SecureDirectoryStream can't be supported on platforms that don't
>> have O_NOFOLLOW so it means that
>> UnixFileSystemProvider.newDirectoryStream will require to check this
>> before deciding the type of DirectoryStream to return.
>
>
> I agree with you. Just simply changing the code in the
> NativeDispatcher's init method will make it happen.
I don't quite understand your comment but the change would be in
UnixFileSystemProvider.newDirectoryStream where it decides whether to
return a UnixDirectoryStream or a UnixSecureDirectoryStream. Where
O_NOFOLLOW is not supported then it will need to return a
UnixDirectoryStream.
>
>>
>> 2. UnixChannelFactory (which is used by
>> UnixFileSystemProvider.newFileChannel and newAsynchronousFileChannel)
>> will need to fail with UOE if NOFOLLOW_LINKS is specified as an
>> option when opening a file. It's not one of the standard opens and so
>> it's required to be supported, it just happens that all the platforms
>> we currently
>
> This part of code is a bit tricky. Because !CREATE_NEW &&
> DELETE_ON_CLOSE will still need O_NOFOLLOW. It will be strange for
> user if they do not know the details of implementation but get
> "Unsupported no follow option" only because they use !CREATE_NEW &&
> DELETE_ON_CLOSE. Can I remove the !CREATE_NEW && DELETE_ON_CLOSE ?
There are two places in UnixChannelFactory. First is Flags.toFlags where
UOE can be thrown if NOFOLLOW_LINKS is specified. The second is the
DELETE_ON_CLOSE case. If O_NOFOLLOW is not supported then all I can
suggest is to lstat the file and fail (by throwing an IOException) if
the file is a sym link. Here's how it is worded in the spec:
"For security reasons, this option may imply the
LinkOption.NOFOLLOW_LINKS option. In other words, if the option is
present when opening an existing file that is a symbolic link then it
may fail (by throwing IOException)"
>
>>
>> 3. Where a FileAttributeView is created that doesn't follow sym links
>> then it's highly platform specific if it can be used to update the
>> attributes of the sym link. This is where
>> UnixPath.openForAttributeAccess is used. I need to double check the
>> javadoc to see how this is specified as I can't recall off-hand if
>> this is treated as an UOE or an IOException (I think the latter).
>>
>
> From the code and doc, I guess it throws IOException. It is
> interesting that methods in the FileSystemProvider throw UOE because
> not supporting specific attribute view, not include not supporting
> options. Can we add this in the doc? I'd like a UOE been throw in the
> FileSystemProvider if a method is provided a NOFOLLOW_LINKS on the
> platform which is not supported O_NOFOLLOW. This will include all the
> methods which has option as its parameter in the FileSystemProvider.
> What do you think, Alan?
I thought we had wording in the spec to cover this but I'm unable to
find it. As I'm sure you will understand, changing the attributes of a
symbolic link is not very interesting, not feasible in all cases, and
the intention is that a provider is not required to support it. I will
create a bug to get the javadoc clarified on this point. Given that a
provider may support the updating of some attributes, and may not be
able update other attributes then all we can do is have the appropriate
set* method fail with an IOException. For example your platform may
support lchown, in which case it will be able to change the owner of a
symbolic link (not interesting but possible). Given that O_NOFOLLOW is
the issue for you then I think that all issues should be covered by
changing UnixPath.openForAttributeAccess to throw IOException when
followLinks is false.
-Alan
From littlee at linux.vnet.ibm.com Wed Jan 4 06:44:52 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Wed, 04 Jan 2012 22:44:52 +0800
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F044748.8010706@oracle.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
Message-ID: <4F0465E4.5090404@linux.vnet.ibm.com>
Hi Alan,
On 01/04/2012 08:34 PM, Alan Bateman wrote:
> I don't quite understand your comment but the change would be in
> UnixFileSystemProvider.newDirectoryStream where it decides whether to
> return a UnixDirectoryStream or a UnixSecureDirectoryStream. Where
> O_NOFOLLOW is not supported then it will need to return a
> UnixDirectoryStream.
I was thinking making the UnixNativeDispatcher.supportsAtSysCalls
consistent. But maybe I am wrong. supportsAtSysCalls should only be
judged by "at" functions....
There are some platforms which support "at" functions but do not support
O_NOFOLLOWLINK flag...
You are inspiring me that maybe I should also use lstat some where and
fail only when "NOFOLLOW_LINK meets link" :-)
>
> I thought we had wording in the spec to cover this but I'm unable to
> find it. As I'm sure you will understand, changing the attributes of a
> symbolic link is not very interesting, not feasible in all cases, and
> the intention is that a provider is not required to support it. I will
> create a bug to get the javadoc clarified on this point. Given that a
> provider may support the updating of some attributes, and may not be
> able update other attributes then all we can do is have the
> appropriate set* method fail with an IOException. For example your
> platform may support lchown, in which case it will be able to change
> the owner of a symbolic link (not interesting but possible). Given
> that O_NOFOLLOW is the issue for you then I think that all issues
> should be covered by changing UnixPath.openForAttributeAccess to throw
> IOException when followLinks is false.
>
In the spec NOFOLLOW_LINKS means "Do not follow symbolic links". So if
the platform support lstat, lchown etc, does that mean it support
NOFOLLOW_LINKS? The spec says NOFOLLOW_LINKS like a behavior not a flag
"O_NOFOLLOW".
It may be a stupid question, maybe someone has already ask that...
> -Alan
>
>
>
>
>
--
Yours Charles
From Alan.Bateman at oracle.com Wed Jan 4 07:11:24 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Jan 2012 15:11:24 +0000
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F0465E4.5090404@linux.vnet.ibm.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
<4F0465E4.5090404@linux.vnet.ibm.com>
Message-ID: <4F046C1C.202@oracle.com>
On 04/01/2012 14:44, Charles Lee wrote:
>
> I was thinking making the UnixNativeDispatcher.supportsAtSysCalls
> consistent. But maybe I am wrong. supportsAtSysCalls should only be
> judged by "at" functions....
> There are some platforms which support "at" functions but do not
> support O_NOFOLLOWLINK flag...
> You are inspiring me that maybe I should also use lstat some where and
> fail only when "NOFOLLOW_LINK meets link" :-)
I don't know if there are platforms that support openat but not O_NOFOLLOW.
> :
>
> In the spec NOFOLLOW_LINKS means "Do not follow symbolic links". So if
> the platform support lstat, lchown etc, does that mean it support
> NOFOLLOW_LINKS? The spec says NOFOLLOW_LINKS like a behavior not a
> flag "O_NOFOLLOW".
> It may be a stupid question, maybe someone has already ask that...
I don't think the spec mentions O_NOFOLLOW anywhere but when
NOFOLLOW_LINKS is specified to a method that opens a file (like
Files.newByteChannel) then it adds the O_NOFOLLOW flag so that sym links
aren't followed. The lstat andl chown calls are used read the file
attributes or setting the file owner and sym links aren't specified.
Hopefully it is starting to become clear.
-Alan
From Alan.Bateman at oracle.com Thu Jan 5 07:04:50 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Jan 2012 15:04:50 +0000
Subject: 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed
Message-ID: <4F05BC12.4000807@oracle.com>
This is a faux pas in the implementation of Files.walkFileTree. Where
the attributes of the files in a directory are read as part of the
iteration then they are cached, via a weak reference, to avoid
re-fetching them. Unfortunately this code doesn't check if the reference
has been cleared which can be lead to a NPE as per the bug report. The
fix is to trivially check if the reference has been cleared. This one is
really hard to reproduce and I don't have a reliable test case.
-Alan
diff --git a/src/share/classes/java/nio/file/FileTreeWalker.java
b/src/share/classes/java/nio/file/FileTreeWalker.java
--- a/src/share/classes/java/nio/file/FileTreeWalker.java
+++ b/src/share/classes/java/nio/file/FileTreeWalker.java
@@ -92,7 +92,7 @@ class FileTreeWalker {
(System.getSecurityManager() == null))
{
BasicFileAttributes cached =
((BasicFileAttributesHolder)file).get();
- if (!followLinks || !cached.isSymbolicLink())
+ if (cached != null && (!followLinks ||
!cached.isSymbolicLink()))
attrs = cached;
}
IOException exc = null;
From forax at univ-mlv.fr Thu Jan 5 07:52:49 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 05 Jan 2012 16:52:49 +0100
Subject: 7127235: (fs) NPE in Files.walkFileTree if cached attributes
are GC'ed
In-Reply-To: <4F05BC12.4000807@oracle.com>
References: <4F05BC12.4000807@oracle.com>
Message-ID: <4F05C751.1010003@univ-mlv.fr>
On 01/05/2012 04:04 PM, Alan Bateman wrote:
>
> This is a faux pas in the implementation of Files.walkFileTree. Where
> the attributes of the files in a directory are read as part of the
> iteration then they are cached, via a weak reference, to avoid
> re-fetching them. Unfortunately this code doesn't check if the
> reference has been cleared which can be lead to a NPE as per the bug
> report. The fix is to trivially check if the reference has been
> cleared. This one is really hard to reproduce and I don't have a
> reliable test case.
>
> -Alan
>
> diff --git a/src/share/classes/java/nio/file/FileTreeWalker.java
> b/src/share/classes/java/nio/file/FileTreeWalker.java
> --- a/src/share/classes/java/nio/file/FileTreeWalker.java
> +++ b/src/share/classes/java/nio/file/FileTreeWalker.java
> @@ -92,7 +92,7 @@ class FileTreeWalker {
> (System.getSecurityManager() == null))
> {
> BasicFileAttributes cached =
> ((BasicFileAttributesHolder)file).get();
> - if (!followLinks || !cached.isSymbolicLink())
> + if (cached != null && (!followLinks ||
> !cached.isSymbolicLink()))
> attrs = cached;
> }
> IOException exc = null;
>
Looks Ok for me but I was not able to read the bug report (not available).
cheers,
R?mi
From Alan.Bateman at oracle.com Thu Jan 5 08:13:22 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Jan 2012 16:13:22 +0000
Subject: 7127235: (fs) NPE in Files.walkFileTree if cached attributes
are GC'ed
In-Reply-To: <4F05C751.1010003@univ-mlv.fr>
References: <4F05BC12.4000807@oracle.com> <4F05C751.1010003@univ-mlv.fr>
Message-ID: <4F05CC22.7080604@oracle.com>
On 05/01/2012 15:52, R?mi Forax wrote:
>
> Looks Ok for me but I was not able to read the bug report (not
> available).
>
Thanks. I think the legacy bugs.sun.com site only updates itself once a
day and this one was submitted overnight. Should be visible tomorrow.
-Alan.
From chris.hegarty at oracle.com Thu Jan 5 09:02:39 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 05 Jan 2012 17:02:39 +0000
Subject: 7127235: (fs) NPE in Files.walkFileTree if cached attributes
are GC'ed
In-Reply-To: <4F05BC12.4000807@oracle.com>
References: <4F05BC12.4000807@oracle.com>
Message-ID: <4F05D7AF.5060806@oracle.com>
Looks fine.
-Chris.
On 01/ 5/12 03:04 PM, Alan Bateman wrote:
>
> This is a faux pas in the implementation of Files.walkFileTree. Where
> the attributes of the files in a directory are read as part of the
> iteration then they are cached, via a weak reference, to avoid
> re-fetching them. Unfortunately this code doesn't check if the reference
> has been cleared which can be lead to a NPE as per the bug report. The
> fix is to trivially check if the reference has been cleared. This one is
> really hard to reproduce and I don't have a reliable test case.
>
> -Alan
>
> diff --git a/src/share/classes/java/nio/file/FileTreeWalker.java
> b/src/share/classes/java/nio/file/FileTreeWalker.java
> --- a/src/share/classes/java/nio/file/FileTreeWalker.java
> +++ b/src/share/classes/java/nio/file/FileTreeWalker.java
> @@ -92,7 +92,7 @@ class FileTreeWalker {
> (System.getSecurityManager() == null))
> {
> BasicFileAttributes cached = ((BasicFileAttributesHolder)file).get();
> - if (!followLinks || !cached.isSymbolicLink())
> + if (cached != null && (!followLinks || !cached.isSymbolicLink()))
> attrs = cached;
> }
> IOException exc = null;
>
From littlee at linux.vnet.ibm.com Wed Jan 11 01:00:03 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Wed, 11 Jan 2012 17:00:03 +0800
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F046C1C.202@oracle.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
<4F0465E4.5090404@linux.vnet.ibm.com> <4F046C1C.202@oracle.com>
Message-ID: <4F0D4F93.3020301@linux.vnet.ibm.com>
On 01/04/2012 11:11 PM, Alan Bateman wrote:
> On 04/01/2012 14:44, Charles Lee wrote:
>>
>> I was thinking making the UnixNativeDispatcher.supportsAtSysCalls
>> consistent. But maybe I am wrong. supportsAtSysCalls should only be
>> judged by "at" functions....
>> There are some platforms which support "at" functions but do not
>> support O_NOFOLLOWLINK flag...
>> You are inspiring me that maybe I should also use lstat some where
>> and fail only when "NOFOLLOW_LINK meets link" :-)
> I don't know if there are platforms that support openat but not
> O_NOFOLLOW.
>
>> :
>>
>> In the spec NOFOLLOW_LINKS means "Do not follow symbolic links". So
>> if the platform support lstat, lchown etc, does that mean it support
>> NOFOLLOW_LINKS? The spec says NOFOLLOW_LINKS like a behavior not a
>> flag "O_NOFOLLOW".
>> It may be a stupid question, maybe someone has already ask that...
> I don't think the spec mentions O_NOFOLLOW anywhere but when
> NOFOLLOW_LINKS is specified to a method that opens a file (like
> Files.newByteChannel) then it adds the O_NOFOLLOW flag so that sym
> links aren't followed. The lstat andl chown calls are used read the
> file attributes or setting the file owner and sym links aren't
> specified. Hopefully it is starting to become clear.
>
> -Alan
>
Hi Alan,
Sorry for the late reply. I found my self on a very long way to get the
popular machine which is not support O_NOFOLLOW :-)
Please help to review the latest patch. It is at
http://cr.openjdk.java.net/~littlee/OJDK-226/webrev.01/
Thank you very much.
--
Yours Charles
From Alan.Bateman at oracle.com Wed Jan 11 03:48:57 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jan 2012 11:48:57 +0000
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F0D4F93.3020301@linux.vnet.ibm.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
<4F0465E4.5090404@linux.vnet.ibm.com> <4F046C1C.202@oracle.com>
<4F0D4F93.3020301@linux.vnet.ibm.com>
Message-ID: <4F0D7729.3020001@oracle.com>
On 11/01/2012 09:00, Charles Lee wrote:
>
> Hi Alan,
>
> Sorry for the late reply. I found my self on a very long way to get
> the popular machine which is not support O_NOFOLLOW :-)
>
> Please help to review the latest patch. It is at
> http://cr.openjdk.java.net/~littlee/OJDK-226/webrev.01/
>
>
> Thank you very much.
>
This looks quite good.
The only problem I see is in UnixChannelFactory L224-225 where you check
if the file is a sym link. If CREATE is specified and the file doesn't
previously exist then this code will end up throwing an exception. Two
other points on this are (a) I also think NOFOLLOW_LINKS should be
rejected earlier, and (b) since we are accessing the file system to
check the file then I think IOException would be better than UOE. So for
UnixChannelFactory I suggest the following:
@@ -86,13 +84,13 @@ class UnixChannelFactory {
}
continue;
}
- if (option == LinkOption.NOFOLLOW_LINKS) {
+ if (option == LinkOption.NOFOLLOW_LINKS &&
supportsNoFollowLinks()) {
flags.noFollowLinks = true;
continue;
}
if (option == null)
throw new NullPointerException();
- throw new UnsupportedOperationException();
+ throw new UnsupportedOperationException(option + " not
supported");
}
return flags;
}
@@ -220,6 +218,15 @@ class UnixChannelFactory {
// follow links by default
boolean followLinks = true;
if (!flags.createNew && (flags.noFollowLinks ||
flags.deleteOnClose)) {
+ if (flags.deleteOnClose && !supportsNoFollowLinks()) {
+ try {
+ if (UnixFileAttributes.get(path,
false).isSymbolicLink())
+ throw new UnixException("DELETE_ON_CLOSE
specified and file is a symbolic link");
+ } catch (UnixException x) {
+ if (!flags.create || x.errno() != ENOENT)
+ throw x;
+ }
+ }
followLinks = false;
oflags |= O_NOFOLLOW;
}
Otherwise I have only minor comments:
1. In UnixNativeDispatcher. supportsNoFollowLinks then it would be
better to check if O_NOFOLLOW != 0 (just case it's not a positive value).
2. In genUnixConstants.c I think we should include a small comment to be
consistent with AT_SYMLINK_NOFOLLOW.
3. UnixPath - really minor comment is that the braces aren't needed and
best to be locally consistent.
-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120111/ee845004/attachment.html
From Alan.Bateman at oracle.com Wed Jan 11 03:52:25 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jan 2012 11:52:25 +0000
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F0D4F93.3020301@linux.vnet.ibm.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
<4F0465E4.5090404@linux.vnet.ibm.com> <4F046C1C.202@oracle.com>
<4F0D4F93.3020301@linux.vnet.ibm.com>
Message-ID: <4F0D77F9.8050604@oracle.com>
I should have mentioned, I've created a bug to track this:
7129029: (fs) Unix file system provider should be buildable on platforms
that don't support O_NOFOLLOW
-Alan.
From Alan.Bateman at oracle.com Wed Jan 11 04:10:02 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jan 2012 12:10:02 +0000
Subject: 7068856: (file) Typo in Files.isSameFile() javadoc
Message-ID: <4F0D7C1A.3030705@oracle.com>
I need a reviewer for two small typos in the javadoc:
http://bugs.sun.com/view_bug.do?bug_id=7068856
http://bugs.sun.com/view_bug.do?bug_id=7099208
The proposed patch is attached.
Thanks,
Alan.
diff --git a/src/share/classes/java/nio/file/Files.java
b/src/share/classes/java/nio/file/Files.java
--- a/src/share/classes/java/nio/file/Files.java
+++ b/src/share/classes/java/nio/file/Files.java
@@ -1431,7 +1431,7 @@ public final class Files {
* It is transitive: for three {@code Paths}
* {@code f}, {@code g}, and {@code h}, if {@code
isSameFile(f,g)} returns
* {@code true} and {@code isSameFile(g,h)} returns {@code
true}, then
- * {@code isSameFile(g,h)} will return return {@code true}.
+ * {@code isSameFile(f,h)} will return return {@code true}.
*
*
* @param path
diff --git a/src/share/classes/java/nio/file/Path.java
b/src/share/classes/java/nio/file/Path.java
--- a/src/share/classes/java/nio/file/Path.java
+++ b/src/share/classes/java/nio/file/Path.java
@@ -72,7 +72,7 @@ import java.util.Iterator;
* directory and is UTF-8 encoded.
*
* Path path = FileSystems.getDefault().getPath("logs", "access.log");
- * BufferReader reader = Files.newBufferedReader(path,
StandardCharsets.UTF_8);
+ * BufferedReader reader = Files.newBufferedReader(path,
StandardCharsets.UTF_8);
*
*
* Interoperability
From forax at univ-mlv.fr Wed Jan 11 04:25:46 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 11 Jan 2012 13:25:46 +0100
Subject: 7068856: (file) Typo in Files.isSameFile() javadoc
In-Reply-To: <4F0D7C1A.3030705@oracle.com>
References: <4F0D7C1A.3030705@oracle.com>
Message-ID: <4F0D7FCA.4090409@univ-mlv.fr>
On 01/11/2012 01:10 PM, Alan Bateman wrote:
>
> I need a reviewer for two small typos in the javadoc:
>
> http://bugs.sun.com/view_bug.do?bug_id=7068856
> http://bugs.sun.com/view_bug.do?bug_id=7099208
>
> The proposed patch is attached.
OK for me.
>
> Thanks,
> Alan.
cheers,
R?mi
>
>
>
> diff --git a/src/share/classes/java/nio/file/Files.java
> b/src/share/classes/java/nio/file/Files.java
> --- a/src/share/classes/java/nio/file/Files.java
> +++ b/src/share/classes/java/nio/file/Files.java
> @@ -1431,7 +1431,7 @@ public final class Files {
> * It is transitive: for three {@code Paths}
> * {@code f}, {@code g}, and {@code h}, if {@code
> isSameFile(f,g)} returns
> * {@code true} and {@code isSameFile(g,h)} returns {@code
> true}, then
> - * {@code isSameFile(g,h)} will return return {@code true}.
> + * {@code isSameFile(f,h)} will return return {@code true}.
> *
> *
> * @param path
> diff --git a/src/share/classes/java/nio/file/Path.java
> b/src/share/classes/java/nio/file/Path.java
> --- a/src/share/classes/java/nio/file/Path.java
> +++ b/src/share/classes/java/nio/file/Path.java
> @@ -72,7 +72,7 @@ import java.util.Iterator;
> * directory and is UTF-8 encoded.
> *
> * Path path = FileSystems.getDefault().getPath("logs",
> "access.log");
> - * BufferReader reader = Files.newBufferedReader(path,
> StandardCharsets.UTF_8);
> + * BufferedReader reader = Files.newBufferedReader(path,
> StandardCharsets.UTF_8);
> *
> *
> * Interoperability
>
From chris.hegarty at oracle.com Wed Jan 11 05:09:49 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 11 Jan 2012 13:09:49 +0000
Subject: 7068856: (file) Typo in Files.isSameFile() javadoc
In-Reply-To: <4F0D7FCA.4090409@univ-mlv.fr>
References: <4F0D7C1A.3030705@oracle.com> <4F0D7FCA.4090409@univ-mlv.fr>
Message-ID: <4F0D8A1D.8050103@oracle.com>
On 11/01/2012 12:25, R?mi Forax wrote:
> On 01/11/2012 01:10 PM, Alan Bateman wrote:
>>
>> I need a reviewer for two small typos in the javadoc:
>>
>> http://bugs.sun.com/view_bug.do?bug_id=7068856
>> http://bugs.sun.com/view_bug.do?bug_id=7099208
>>
>> The proposed patch is attached.
>
> OK for me.
+1
-Chris.
>
>>
>> Thanks,
>> Alan.
>
> cheers,
> R?mi
>
>>
>>
>>
>> diff --git a/src/share/classes/java/nio/file/Files.java
>> b/src/share/classes/java/nio/file/Files.java
>> --- a/src/share/classes/java/nio/file/Files.java
>> +++ b/src/share/classes/java/nio/file/Files.java
>> @@ -1431,7 +1431,7 @@ public final class Files {
>> * It is transitive: for three {@code Paths}
>> * {@code f}, {@code g}, and {@code h}, if {@code isSameFile(f,g)} returns
>> * {@code true} and {@code isSameFile(g,h)} returns {@code true}, then
>> - * {@code isSameFile(g,h)} will return return {@code true}.
>> + * {@code isSameFile(f,h)} will return return {@code true}.
>> *
>> *
>> * @param path
>> diff --git a/src/share/classes/java/nio/file/Path.java
>> b/src/share/classes/java/nio/file/Path.java
>> --- a/src/share/classes/java/nio/file/Path.java
>> +++ b/src/share/classes/java/nio/file/Path.java
>> @@ -72,7 +72,7 @@ import java.util.Iterator;
>> * directory and is UTF-8 encoded.
>> *
>> * Path path = FileSystems.getDefault().getPath("logs", "access.log");
>> - * BufferReader reader = Files.newBufferedReader(path,
>> StandardCharsets.UTF_8);
>> + * BufferedReader reader = Files.newBufferedReader(path,
>> StandardCharsets.UTF_8);
>> *
>> *
>> * Interoperability
>>
>
From mike.duigou at oracle.com Wed Jan 11 08:11:14 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 11 Jan 2012 08:11:14 -0800
Subject: 7068856: (file) Typo in Files.isSameFile() javadoc
In-Reply-To: <4F0D7C1A.3030705@oracle.com>
References: <4F0D7C1A.3030705@oracle.com>
Message-ID: <0FA15705-737C-49E9-9F5B-C1DC4585503C@oracle.com>
Both look good.
Mike
On Jan 11 2012, at 04:10 , Alan Bateman wrote:
>
> I need a reviewer for two small typos in the javadoc:
>
> http://bugs.sun.com/view_bug.do?bug_id=7068856
> http://bugs.sun.com/view_bug.do?bug_id=7099208
>
> The proposed patch is attached.
>
> Thanks,
> Alan.
>
>
>
> diff --git a/src/share/classes/java/nio/file/Files.java b/src/share/classes/java/nio/file/Files.java
> --- a/src/share/classes/java/nio/file/Files.java
> +++ b/src/share/classes/java/nio/file/Files.java
> @@ -1431,7 +1431,7 @@ public final class Files {
> * It is transitive: for three {@code Paths}
> * {@code f}, {@code g}, and {@code h}, if {@code isSameFile(f,g)} returns
> * {@code true} and {@code isSameFile(g,h)} returns {@code true}, then
> - * {@code isSameFile(g,h)} will return return {@code true}.
> + * {@code isSameFile(f,h)} will return return {@code true}.
> *
> *
> * @param path
> diff --git a/src/share/classes/java/nio/file/Path.java b/src/share/classes/java/nio/file/Path.java
> --- a/src/share/classes/java/nio/file/Path.java
> +++ b/src/share/classes/java/nio/file/Path.java
> @@ -72,7 +72,7 @@ import java.util.Iterator;
> * directory and is UTF-8 encoded.
> *
> * Path path = FileSystems.getDefault().getPath("logs", "access.log");
> - * BufferReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8);
> + * BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8);
> *
> *
> * Interoperability
>
From littlee at linux.vnet.ibm.com Wed Jan 11 23:02:35 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Thu, 12 Jan 2012 15:02:35 +0800
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F0D77F9.8050604@oracle.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
<4F0465E4.5090404@linux.vnet.ibm.com> <4F046C1C.202@oracle.com>
<4F0D4F93.3020301@linux.vnet.ibm.com> <4F0D77F9.8050604@oracle.com>
Message-ID: <4F0E858B.3050404@linux.vnet.ibm.com>
On 01/11/2012 07:52 PM, Alan Bateman wrote:
> I should have mentioned, I've created a bug to track this:
>
> 7129029: (fs) Unix file system provider should be buildable on
> platforms that don't support O_NOFOLLOW
>
> -Alan.
>
Hi Alan,
Thank you for your review. I have upload a new version on
http://cr.openjdk.java.net/~littlee/7129029/webrev.00/
.
Would you please help to check it again? Apart from your suggestion, I
also make some changes in UnixCopyFile.java. The situation is the same
as it is in the UnixChannelFactory.java.
Thanks in advance :-)
--
Yours Charles
From Alan.Bateman at oracle.com Thu Jan 12 01:43:07 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Jan 2012 09:43:07 +0000
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F0E858B.3050404@linux.vnet.ibm.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
<4F0465E4.5090404@linux.vnet.ibm.com> <4F046C1C.202@oracle.com>
<4F0D4F93.3020301@linux.vnet.ibm.com> <4F0D77F9.8050604@oracle.com>
<4F0E858B.3050404@linux.vnet.ibm.com>
Message-ID: <4F0EAB2B.7070601@oracle.com>
On 12/01/2012 07:02, Charles Lee wrote:
>
> Hi Alan,
>
> Thank you for your review. I have upload a new version on
> http://cr.openjdk.java.net/~littlee/7129029/webrev.00/
> .
> Would you please help to check it again? Apart from your suggestion, I
> also make some changes in UnixCopyFile.java. The situation is the same
> as it is in the UnixChannelFactory.java.
>
> Thanks in advance :-)
>
The changes to UnixCopyFile.java will break copying of sym links (in
Files.copy you'll see that it is specified to support NOFOLLOW_LINKS).
The implementation doesn't depend on O_NOFOLLOW support so I don't think
any changes are required.
UnixChannelFactory.java L224 - this needs to throw UnixException rather
than UOE. This will be handled and translated into the appropriate
IOException (actually FileSystemException).
Otherwise the changes look okay to me.
-Alan.
From littlee at linux.vnet.ibm.com Thu Jan 12 21:34:05 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Fri, 13 Jan 2012 13:34:05 +0800
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F0EAB2B.7070601@oracle.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
<4F0465E4.5090404@linux.vnet.ibm.com> <4F046C1C.202@oracle.com>
<4F0D4F93.3020301@linux.vnet.ibm.com> <4F0D77F9.8050604@oracle.com>
<4F0E858B.3050404@linux.vnet.ibm.com> <4F0EAB2B.7070601@oracle.com>
Message-ID: <4F0FC24D.3040900@linux.vnet.ibm.com>
On 01/12/2012 05:43 PM, Alan Bateman wrote:
> On 12/01/2012 07:02, Charles Lee wrote:
>>
>> Hi Alan,
>>
>> Thank you for your review. I have upload a new version on
>> http://cr.openjdk.java.net/~littlee/7129029/webrev.00/
>> .
>> Would you please help to check it again? Apart from your suggestion,
>> I also make some changes in UnixCopyFile.java. The situation is the
>> same as it is in the UnixChannelFactory.java.
>>
>> Thanks in advance :-)
>>
> The changes to UnixCopyFile.java will break copying of sym links (in
> Files.copy you'll see that it is specified to support NOFOLLOW_LINKS).
> The implementation doesn't depend on O_NOFOLLOW support so I don't
> think any changes are required.
I am thinking NOFOLLOW_LINKS is not O_NOFOLLOW again and again....
On the platform, which does not support O_NOFOLLOW, there will be
occurred that some api supports NOFOLLOW_LINKS, others are not. This
will be a little confusing.
I agree that, if the implementation does not depend on O_NOFOLLOW,
NOFOLLOW_LINKS should be allowed. So I am continuing to think that in
the place where O_NOFOLLOW is used, we can check it to see whether it is
sym link to stimulate the behaviour of O_NOFOLLOW flag. It means in
UnixPath.openForAttributeAccess, we can stimulate O_NOFOLLOW with sym
link checking. It maybe also means we can stimulate O_NOFOLLOW in the
SecureDirectoryStream to let platform (AIX 7.1) support more powerful
directory stream without O_NOFOLLOW supported. Unfortunately, I am
looping ...
>
> UnixChannelFactory.java L224 - this needs to throw UnixException
> rather than UOE. This will be handled and translated into the
> appropriate IOException (actually FileSystemException).
>
> Otherwise the changes look okay to me.
>
> -Alan.
>
Please check: http://cr.openjdk.java.net/~littlee/7129029/webrev.01/
--
Yours Charles
From Alan.Bateman at oracle.com Fri Jan 13 05:35:15 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Jan 2012 13:35:15 +0000
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F0FC24D.3040900@linux.vnet.ibm.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
<4F0465E4.5090404@linux.vnet.ibm.com> <4F046C1C.202@oracle.com>
<4F0D4F93.3020301@linux.vnet.ibm.com> <4F0D77F9.8050604@oracle.com>
<4F0E858B.3050404@linux.vnet.ibm.com> <4F0EAB2B.7070601@oracle.com>
<4F0FC24D.3040900@linux.vnet.ibm.com>
Message-ID: <4F103313.2050603@oracle.com>
On 13/01/2012 05:34, Charles Lee wrote:
>
> I am thinking NOFOLLOW_LINKS is not O_NOFOLLOW again and again....
> On the platform, which does not support O_NOFOLLOW, there will be
> occurred that some api supports NOFOLLOW_LINKS, others are not. This
> will be a little confusing.
Right, LinkOption.NOFOLLOW_LINKS does not imply O_NOFOLLOW is needed.
For example the following:
Files.readAttributes(file, NOFOLLOW_LINKS) or
Files.copy(source, target, NOFOLLOW_LINKS)
don't require using the O_NOFOLLOW flag.
> :
>
> Please check: http://cr.openjdk.java.net/~littlee/7129029/webrev.01/
>
>
I'm happy with this I have pushed it on your behalf:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e593aa6ad41
-Alan.
From littlee at linux.vnet.ibm.com Sun Jan 15 19:25:39 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Mon, 16 Jan 2012 11:25:39 +0800
Subject: Give default value of O_NOFOLLOW if it is not defined
In-Reply-To: <4F103313.2050603@oracle.com>
References: <4EFAB879.9040208@linux.vnet.ibm.com> <4EFAF45B.8040400@oracle.com>
<4EFBDE35.8020905@linux.vnet.ibm.com> <4EFDD874.6070608@oracle.com>
<4F04096A.2010404@linux.vnet.ibm.com> <4F044748.8010706@oracle.com>
<4F0465E4.5090404@linux.vnet.ibm.com> <4F046C1C.202@oracle.com>
<4F0D4F93.3020301@linux.vnet.ibm.com> <4F0D77F9.8050604@oracle.com>
<4F0E858B.3050404@linux.vnet.ibm.com> <4F0EAB2B.7070601@oracle.com>
<4F0FC24D.3040900@linux.vnet.ibm.com> <4F103313.2050603@oracle.com>
Message-ID: <4F1398B3.1070803@linux.vnet.ibm.com>
On 01/13/2012 09:35 PM, Alan Bateman wrote:
> On 13/01/2012 05:34, Charles Lee wrote:
>>
>> I am thinking NOFOLLOW_LINKS is not O_NOFOLLOW again and again....
>> On the platform, which does not support O_NOFOLLOW, there will be
>> occurred that some api supports NOFOLLOW_LINKS, others are not. This
>> will be a little confusing.
> Right, LinkOption.NOFOLLOW_LINKS does not imply O_NOFOLLOW is needed.
> For example the following:
>
> Files.readAttributes(file, NOFOLLOW_LINKS) or
> Files.copy(source, target, NOFOLLOW_LINKS)
>
> don't require using the O_NOFOLLOW flag.
>
>> :
>>
>> Please check: http://cr.openjdk.java.net/~littlee/7129029/webrev.01/
>>
>>
> I'm happy with this I have pushed it on your behalf:
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e593aa6ad41
>
> -Alan.
>
That's great. Thank you very much, Alan.
--
Yours Charles
From andrebargull at googlemail.com Mon Jan 16 03:10:24 2012
From: andrebargull at googlemail.com (=?ISO-8859-15?Q?Andr=E9_Bargull?=)
Date: Mon, 16 Jan 2012 12:10:24 +0100
Subject: Clarification on AbstractInterruptibleChannel#end(), possible bug?
Message-ID: <4F1405A0.7040101@googlemail.com>
java.nio.channels.spi.AbstractInterruptibleChannel#end() contains the
following lines of code:
> Thread interrupted = this.interrupted;
> if (interrupted != null && interrupted == Thread.currentThread()) {
> interrupted = null;
> throw new ClosedByInterruptException();
> }
The assignment "interrupted = null" clearly doesn't make any sense here.
I guess it is supposed to be "this.interrupted = null"?
- Andr?
From Alan.Bateman at oracle.com Mon Jan 16 03:29:00 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Jan 2012 11:29:00 +0000
Subject: Clarification on AbstractInterruptibleChannel#end(), possible bug?
In-Reply-To: <4F1405A0.7040101@googlemail.com>
References: <4F1405A0.7040101@googlemail.com>
Message-ID: <4F1409FC.3020901@oracle.com>
On 16/01/2012 11:10, Andr? Bargull wrote:
> java.nio.channels.spi.AbstractInterruptibleChannel#end() contains the
> following lines of code:
>> Thread interrupted = this.interrupted;
>> if (interrupted != null && interrupted == Thread.currentThread()) {
>> interrupted = null;
>> throw new ClosedByInterruptException();
>> }
>
> The assignment "interrupted = null" clearly doesn't make any sense
> here. I guess it is supposed to be "this.interrupted = null"?
You're right, this isn't needed and could be this.interrupted = null to
avoid other threads doing I/O on the channel from needing to check if
they are interrupted.
-Alan.
From vladimir.danushevsky at oracle.com Tue Jan 24 20:42:16 2012
From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky)
Date: Tue, 24 Jan 2012 23:42:16 -0500
Subject: review request: 7114611 - SIGBUS in readdir64_r
In-Reply-To: <4F1F1DEA.8070707@Oracle.com>
References: <4F1F1DEA.8070707@Oracle.com>
Message-ID: <051B1815-C8C6-4825-BE5E-AA7151B9B54B@oracle.com>
cc'ing nio-dev at openjdk.java.net
I'm not sure regarding name_extra char array size calculation. Does it
need to be just (PATH_MAX+1) instead?
On Jan 24, 2012, at 4:08 PM, Carlos Lucasius wrote:
> http://javaweb.us.oracle.com/~clucasiu/webrevs/7114611/webrev.00/
>
> Thanks,
>
> -Carlos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120124/3b1e7416/attachment.html
From dean.long at oracle.com Tue Jan 24 23:29:46 2012
From: dean.long at oracle.com (Dean Long)
Date: Tue, 24 Jan 2012 23:29:46 -0800
Subject: review request: 7114611 - SIGBUS in readdir64_r
In-Reply-To: <051B1815-C8C6-4825-BE5E-AA7151B9B54B@oracle.com>
References: <4F1F1DEA.8070707@Oracle.com>
<051B1815-C8C6-4825-BE5E-AA7151B9B54B@oracle.com>
Message-ID: <4F1FAF6A.9080206@oracle.com>
Using name_extra[PATH_MAX + 1] would reserve more space than needed.
The suggested fix that I contributed results in something like:
struct {
struct /* dirent64 */ {
/* ... */|
char d_name[256 /* unspecified */];
} buf;
| char name_extra[PATH_MAX + 1 - sizeof result->d_name];
} entry;
When you combine the adjacent buf.d_name[] and name_extra[], you get
PATH_MAX + 1 char's. But that is already more than enough.
I chose PATH_MAX + 1 because that's what the old code did,
but according to the spec only NAME_MAX + 1 char's need to be reserved.
dl
http://pubs.opengroup.org/onlinepubs/007908799/xsh/readdir_r.html
On 1/24/2012 8:42 PM, Vladimir Danushevsky wrote:
> cc'ing nio-dev at openjdk.java.net
>
> I'm not sure regarding name_extra char array size calculation. Does it
> need to bejust (PATH_MAX+1) instead?
>
> On Jan 24, 2012, at 4:08 PM, Carlos Lucasius wrote:
>
>> http://javaweb.us.oracle.com/~clucasiu/webrevs/7114611/webrev.00/
>>
>> Thanks,
>>
>> /-/Carlos
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120124/f9d2629c/attachment.html
From Alan.Bateman at oracle.com Mon Jan 30 05:13:51 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Jan 2012 13:13:51 +0000
Subject: review request: 7114611 - SIGBUS in readdir64_r
In-Reply-To: <4F1FAF6A.9080206@oracle.com>
References: <4F1F1DEA.8070707@Oracle.com>
<051B1815-C8C6-4825-BE5E-AA7151B9B54B@oracle.com>
<4F1FAF6A.9080206@oracle.com>
Message-ID: <4F26978F.9090000@oracle.com>
On 25/01/2012 07:29, Dean Long wrote:
> Using name_extra[PATH_MAX + 1] would reserve more space than needed.
> The suggested fix that I contributed results in something like:
> struct {
> struct /* dirent64 */ {
> /* ... */|
> char d_name[256 /* unspecified */];
> } buf;
> | char name_extra[PATH_MAX + 1 - sizeof result->d_name];
> } entry;
> When you combine the adjacent buf.d_name[] and name_extra[], you get
> PATH_MAX + 1 char's. But that is already more than enough.
> I chose PATH_MAX + 1 because that's what the old code did,
> but according to the spec only NAME_MAX + 1 char's need to be reserved.
>
> dl
>
> http://pubs.opengroup.org/onlinepubs/007908799/xsh/readdir_r.html
>
I think Dean's suggestion seems reasonable. Ideally we should be using
NAME_MAX but that would require a fpathconf after opening the directory
to get the the max size.
-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120130/2af466fe/attachment.html
From chris.hegarty at oracle.com Mon Jan 30 08:45:06 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 30 Jan 2012 16:45:06 +0000
Subject: 7041778: Move SCTP implementation out of sun.nio.ch and into its
own package
Message-ID: <4F26C912.3090203@oracle.com>
This CR will be used to move the SCTP Java implementation into its own
package, from sun.nio.ch to sun.nio.ch.sctp. There is currently no
restriction that libsctp cannot depend on libnet/nio, so the native
implementation simply needs to reflect the new Java package structure.
As a consequence of moving the SCTP implementation into its own package
some of the package private sun.nio.ch classes need to made public so
the SCTP implementation can access them. Utility classes like IOStatus,
IOUtil, Net, and Util. The SelChImpl interface that the SCTP channels
implement, etc.
http://cr.openjdk.java.net/~chegar/7041778/webrev.00/webrev/
Thanks,
-Chris.
From Ulf.Zibis at gmx.de Mon Jan 30 10:37:41 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 30 Jan 2012 19:37:41 +0100
Subject: 7041778: Move SCTP implementation out of sun.nio.ch and into
its own package
In-Reply-To: <4F26C912.3090203@oracle.com>
References: <4F26C912.3090203@oracle.com>
Message-ID: <4F26E375.6030002@gmx.de>
Many classes of the sctp package are prefixed by Sctp...
Can these prefixes be removed now?
-Ulf
Am 30.01.2012 17:45, schrieb Chris Hegarty:
> This CR will be used to move the SCTP Java implementation into its own package, from sun.nio.ch to
> sun.nio.ch.sctp. There is currently no restriction that libsctp cannot depend on libnet/nio, so
> the native implementation simply needs to reflect the new Java package structure.
>
> As a consequence of moving the SCTP implementation into its own package some of the package
> private sun.nio.ch classes need to made public so the SCTP implementation can access them. Utility
> classes like IOStatus, IOUtil, Net, and Util. The SelChImpl interface that the SCTP channels
> implement, etc.
>
> http://cr.openjdk.java.net/~chegar/7041778/webrev.00/webrev/
>
> Thanks,
> -Chris.
>
From chris.hegarty at oracle.com Mon Jan 30 13:39:50 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 30 Jan 2012 21:39:50 +0000
Subject: 7041778: Move SCTP implementation out of sun.nio.ch and into
its own package
In-Reply-To: <4F26E375.6030002@gmx.de>
References: <4F26C912.3090203@oracle.com> <4F26E375.6030002@gmx.de>
Message-ID: <4F270E26.2020403@oracle.com>
On 01/30/12 06:37 PM, Ulf Zibis wrote:
> Many classes of the sctp package are prefixed by Sctp...
> Can these prefixes be removed now?
Ah yes, I guess they probably can. Thanks Ulf.
Obviously, the original intent was to make them easily identifiable
among the other sun.nio.ch implementation classes.
I've renamed as many as I feel comfortable with. I want to avoid obvious
name conflicts.
http://cr.openjdk.java.net/~chegar/7041778/webrev.01/webrev/
Thanks,
-Chris.
>
> -Ulf
>
>
> Am 30.01.2012 17:45, schrieb Chris Hegarty:
>> This CR will be used to move the SCTP Java implementation into its own
>> package, from sun.nio.ch to sun.nio.ch.sctp. There is currently no
>> restriction that libsctp cannot depend on libnet/nio, so the native
>> implementation simply needs to reflect the new Java package structure.
>>
>> As a consequence of moving the SCTP implementation into its own
>> package some of the package private sun.nio.ch classes need to made
>> public so the SCTP implementation can access them. Utility classes
>> like IOStatus, IOUtil, Net, and Util. The SelChImpl interface that the
>> SCTP channels implement, etc.
>>
>> http://cr.openjdk.java.net/~chegar/7041778/webrev.00/webrev/
>>
>> Thanks,
>> -Chris.
>>