From david.lloyd at redhat.com Tue Feb 1 02:49:41 2011 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 01 Feb 2011 04:49:41 -0600 Subject: /etc/mtab vs. /proc/mounts In-Reply-To: <4D47BB37.3000201@xs4all.nl> References: <4D47157D.8060200@oracle.com> <4D47197E.4@redhat.com> <4D47BB37.3000201@xs4all.nl> Message-ID: <4D47E545.4020607@redhat.com> On 02/01/2011 01:50 AM, John Hendrikx wrote: > David M. Lloyd wrote: >> On 01/31/2011 02:03 PM, Alan Bateman wrote: >>> >>> I think I need help to (re)understand the difference between /etc/mtab >>> and /proc/mounts on Linux. >>> >>> On Linux, our getFileStores() is implemented to essentially enumerate >>> /etc/mtab. That should give a similar list to what df(1) prints although >>> the filtering may be slightly different. On the other hand the >>> getFileStore method to get the FileStore for where a file is located >>> uses /proc/mounts to find the mount point (folks on this list may recall >>> the reasons why we switched to using /proc [1]). Using both leads to at >>> least one reported anomaly where it has been observed that getFileStore >>> returns a FileStore representing the root file system with both a name >>> and type of rootfs but df -T (and getFileStores) report something >>> different (/dev/sda1 and ext4 on one system I tried). I'm trying to >>> figure if this code should be changed and what the right answer is for >>> this case. Any suggestions? >> >> I think you'll find that /proc/mounts returns *both* the rootfs and >> the real filesystem mounted atop it (in other words, the mount point >> can be non-unique). >> >> The rootfs filesystem type is used as an early bootstrap phase in many >> distributions (it replaces the older initramfs IIRC). >> >> That said - /etc/mtab will give you the software's idea of what the >> right mounts are. /proc/mounts will give you *everything* that is >> currently mounted, even if multiple filesystems are mounted in the >> same spot. > Not sure what you mean by that, but if I mount two ISO images on the > same spot (say /iso-image), both of the mounts show up in /etc/mtab, > /proc/mounts and in df, even though only one is accessible. See here: > > # cat /etc/mtab > (...) > /temp/debian.iso /iso-image iso9660 rw,loop=/dev/loop1 0 0 > /temp/ubuntu.iso /iso-image iso9660 rw,loop=/dev/loop2 0 0 > > # cat /proc/mounts > (...) > /dev/loop1 /iso-image iso9660 ro,relatime 0 0 > /dev/loop2 /iso-image iso9660 ro,relatime 0 0 > > # df > Filesystem 1K-blocks Used Available Use% Mounted on > (...) > /temp/debian.iso 1527898 1527898 0 100% /iso-image > /temp/ubuntu.iso 1527898 1527898 0 100% /iso-image > > Note that only the last one mounted is accessible. Sure. My point is that mtab contains whatever the mount command puts in there. /proc/self/mounts contains *everything* (it comes from the kernel, as opposed to a userspace program). -- - DML From chris.hegarty at oracle.com Tue Feb 1 02:56:29 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 01 Feb 2011 10:56:29 +0000 Subject: 7014794: (file) lookupPrincipalByGroupName fails to find NIS group In-Reply-To: <4D431D3A.4090902@oracle.com> References: <4D431D3A.4090902@oracle.com> Message-ID: <4D47E6DD.3010603@oracle.com> The changes look fine. I guess rather than defining RESTARTABLE_RETURN_PTR you could have added the error/notFound value to RESTARTABLE_RETURN? -Chris. On 01/28/11 07:47 PM, Alan Bateman wrote: > > The lookupPrincipalByGroupName method is currently failing with NIS > groups that have a lot of members. There is also an issue going the > other way (gid -> group) where the GroupPrincipal's getName or toString > method returns the gid rather than the group name. The problem is that > the implementation uses a buffer of size SC_GETGR_R_SIZE_MAX which is > not sufficient for large groups. The fix bumps up the buffer size until > it is sufficient for the size of the group entry. The webrev with the > changes is here: > http://cr.openjdk.java.net/~alanb/7014794/webrev/ > > Thanks, > Alan. From Alan.Bateman at oracle.com Thu Feb 3 04:37:21 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Feb 2011 12:37:21 +0000 Subject: /etc/mtab vs. /proc/mounts In-Reply-To: <4D47197E.4@redhat.com> References: <4D47157D.8060200@oracle.com> <4D47197E.4@redhat.com> Message-ID: <4D4AA181.10404@oracle.com> Thanks for all the replies, I've been about thinking about what to do with this. On FileSystem.getFileStores then it might be a bit confusing to developers if it enumerated underlying file systems that aren't normally shown by df and mount. For that reason it may be more consistent to just use /etc/mtab as it is doing now (and perhaps with some additional filtering, say to exclude entries that the automounter may have added). If getFileStores is using /etc/mtab then it's probably best if getFileStore also uses /etc/mtab. If not found then it could fallback to /proc/mounts if it is different file (we can use the st_dev/st_ino to check that). The overlaid mounts issue does seem tricky. I don't know how "df -T file..." does this but I suspect it's the first match. If so, then having getFileStore work this way is probably best. Worse case is that the for-informational purposes name and type aren't as expected. I should mention this code is simpler in the Solaris implementation because the extmnttab structure returned by getextmntent gives us the device major/minor number so we can match that up to the st_dev of the file. While looking into this I see that the Linux 2.6.26 kernel added /proc/self/mountinfo and that seems to have the information we need, including an ID for the mount and its parent, and the device major/minor number. -Alan From Alan.Bateman at oracle.com Thu Feb 3 05:30:04 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Feb 2011 13:30:04 +0000 Subject: 7014794: (file) lookupPrincipalByGroupName fails to find NIS group In-Reply-To: <4D47E6DD.3010603@oracle.com> References: <4D431D3A.4090902@oracle.com> <4D47E6DD.3010603@oracle.com> Message-ID: <4D4AADDC.3070500@oracle.com> Chris Hegarty wrote: > The changes look fine. > > I guess rather than defining RESTARTABLE_RETURN_PTR you could have > added the error/notFound value to RESTARTABLE_RETURN? Thanks for looking at this. The reason for RESTARTABLE_RETURN_PTR is that the reentrant functions on Solaris return a pointer to the password or group structure rather than the usual int to indicate success or error. -Alan From chris.hegarty at oracle.com Thu Feb 3 05:30:50 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 03 Feb 2011 13:30:50 +0000 Subject: 7014794: (file) lookupPrincipalByGroupName fails to find NIS group In-Reply-To: <4D4AADDC.3070500@oracle.com> References: <4D431D3A.4090902@oracle.com> <4D47E6DD.3010603@oracle.com> <4D4AADDC.3070500@oracle.com> Message-ID: <4D4AAE0A.9010401@oracle.com> On 02/ 3/11 01:30 PM, Alan Bateman wrote: > Chris Hegarty wrote: >> The changes look fine. >> >> I guess rather than defining RESTARTABLE_RETURN_PTR you could have >> added the error/notFound value to RESTARTABLE_RETURN? > Thanks for looking at this. > > The reason for RESTARTABLE_RETURN_PTR is that the reentrant functions on > Solaris return a pointer to the password or group structure rather than > the usual int to indicate success or error. OK, thanks. I'm fine with the changes. -Chris. > > -Alan From Alan.Bateman at oracle.com Sat Feb 5 08:39:48 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 05 Feb 2011 16:39:48 +0000 Subject: 7012823: TEST_BUG: java/nio/MappedByteBuffer tests leave file mappings that prevent clean-up (win) Message-ID: <4D4D7D54.4000800@oracle.com> Two of the MappedByteBuffer tests fail intermittently on Windows when running jtreg with -retain:fail,error. The tests don't actually fail but rather it's that jtreg can't remove the files that the tests leave behind. To avoid these failure I'd like to change these tests so that they use files in the temporary file directory and in addition, do a GC+sleep at the end to improve the change that the files will be unmapped before the VM terminates. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7012823/webrev/ Thanks, Alan. From Alan.Bateman at oracle.com Sat Feb 5 12:31:13 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 05 Feb 2011 20:31:13 +0000 Subject: 7017454: Residual warnings in sun/nio/** and java/io native code (win64) Message-ID: <4D4DB391.7020202@oracle.com> Whac-A-Mole time again with compiler warnings. This time its the VS2010 compiler on Windows 64-bit, not sure how I missed these the last time. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7017454/webrev/ Thanks, Alan. From forax at univ-mlv.fr Mon Feb 7 01:13:22 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 07 Feb 2011 10:13:22 +0100 Subject: 7012823: TEST_BUG: java/nio/MappedByteBuffer tests leave file mappings that prevent clean-up (win) In-Reply-To: <4D4D7D54.4000800@oracle.com> References: <4D4D7D54.4000800@oracle.com> Message-ID: <4D4FB7B2.4000609@univ-mlv.fr> Le 05/02/2011 17:39, Alan Bateman a ?crit : > > Two of the MappedByteBuffer tests fail intermittently on Windows when > running jtreg with -retain:fail,error. The tests don't actually fail > but rather it's that jtreg can't remove the files that the tests leave > behind. To avoid these failure I'd like to change these tests so that > they use files in the temporary file directory and in addition, do a > GC+sleep at the end to improve the change that the files will be > unmapped before the VM terminates. The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/7012823/webrev/ > > Thanks, > Alan. Looks good. R?mi From chris.hegarty at oracle.com Mon Feb 7 06:34:54 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 07 Feb 2011 14:34:54 +0000 Subject: 7017454: Residual warnings in sun/nio/** and java/io native code (win64) In-Reply-To: <4D4DB391.7020202@oracle.com> References: <4D4DB391.7020202@oracle.com> Message-ID: <4D50030E.1060904@oracle.com> Looks good Alan. -Chris. On 05/02/2011 20:31, Alan Bateman wrote: > Whac-A-Mole time again with compiler warnings. This time its the VS2010 > compiler on Windows 64-bit, not sure how I missed these the last time. > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/7017454/webrev/ > > Thanks, > Alan. From Alan.Bateman at oracle.com Mon Feb 14 02:33:48 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Feb 2011 10:33:48 +0000 Subject: 7016704: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with new version of find (lnx) Message-ID: <4D59050C.2050300@oracle.com> One of the tests for Files.walkFileTree is failing on some (newer) Linux distributions. The test checks the behavior in the presence of cycles by comparing the files visited by the method with the files printed by the find(1) utility. There are different versions of the find utility, some print cycles to stdout, other versions report errors to stderr. The test is intended to work with either version but it seems that I didn't properly tested it with both versions when we added FileSystemLoopException a few months back [1]. The bug is that the PrintFileTree class, used by the test to print the file tree, aborts with an exception when not involved with -reportCycles. The result is that the output doesn't match when running on distributions that have the version of find(1) that doesn't print cycles to stdout. The webrev with the update to the test is here: http://cr.openjdk.java.net/~alanb/7016704/webrev/ Thanks, Alan. [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/81b0c1e3d5a7 From forax at univ-mlv.fr Mon Feb 14 06:03:28 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Feb 2011 15:03:28 +0100 Subject: 7016704: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with new version of find (lnx) In-Reply-To: <4D59050C.2050300@oracle.com> References: <4D59050C.2050300@oracle.com> Message-ID: <4D593630.7030601@univ-mlv.fr> Le 14/02/2011 11:33, Alan Bateman a ?crit : > > One of the tests for Files.walkFileTree is failing on some (newer) > Linux distributions. The test checks the behavior in the presence of > cycles by comparing the files visited by the method with the files > printed by the find(1) utility. There are different versions of the > find utility, some print cycles to stdout, other versions report > errors to stderr. The test is intended to work with either version but > it seems that I didn't properly tested it with both versions when we > added FileSystemLoopException a few months back [1]. The bug is that > the PrintFileTree class, used by the test to print the file tree, > aborts with an exception when not involved with -reportCycles. The > result is that the output doesn't match when running on distributions > that have the version of find(1) that doesn't print cycles to stdout. > The webrev with the update to the test is here: > http://cr.openjdk.java.net/~alanb/7016704/webrev/ > > Thanks, > Alan. > > [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/81b0c1e3d5a7 Alan, I don't understand assert exc != null; Unlike in postVisitDirectory(), in visitFileFailed() the exception should be never null. I think the assert should be move before the if. R?mi From Alan.Bateman at oracle.com Mon Feb 14 06:13:29 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Feb 2011 14:13:29 +0000 Subject: 7016704: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with new version of find (lnx) In-Reply-To: <4D593630.7030601@univ-mlv.fr> References: <4D59050C.2050300@oracle.com> <4D593630.7030601@univ-mlv.fr> Message-ID: <4D593889.9000306@oracle.com> R?mi Forax wrote: > > Alan, > I don't understand > > assert exc != null; > > Unlike in postVisitDirectory(), in visitFileFailed() the exception > should be never null. > I think the assert should be move before the if. > The visitFileFailed method is always called with an IOException and so exc is never null. We can get rid of assert, it's not needed - is that what you mean? -Alan. From forax at univ-mlv.fr Mon Feb 14 09:19:10 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Feb 2011 18:19:10 +0100 Subject: 7016704: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with new version of find (lnx) In-Reply-To: <4D593889.9000306@oracle.com> References: <4D59050C.2050300@oracle.com> <4D593630.7030601@univ-mlv.fr> <4D593889.9000306@oracle.com> Message-ID: <4D59640E.1080700@univ-mlv.fr> On 02/14/2011 03:13 PM, Alan Bateman wrote: > R?mi Forax wrote: >> >> Alan, >> I don't understand >> >> assert exc != null; >> >> Unlike in postVisitDirectory(), in visitFileFailed() the exception >> should be never null. >> I think the assert should be move before the if. >> > The visitFileFailed method is always called with an IOException and so > exc is never null. We can get rid of assert, it's not needed - is that > what you mean? > > -Alan. Get rid of it or put it on top of visitFileFailed(). The question was more, why put that assert only in the else branch ? R?mi From Alan.Bateman at oracle.com Mon Feb 14 09:37:29 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Feb 2011 17:37:29 +0000 Subject: 7016704: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with new version of find (lnx) In-Reply-To: <4D59640E.1080700@univ-mlv.fr> References: <4D59050C.2050300@oracle.com> <4D593630.7030601@univ-mlv.fr> <4D593889.9000306@oracle.com> <4D59640E.1080700@univ-mlv.fr> Message-ID: <4D596859.8040806@oracle.com> R?mi Forax wrote: > : > Get rid of it or put it on top of visitFileFailed(). > The question was more, why put that assert only in the else branch ? Thanks. I'll remove it, it's not needed. -Alan. From Alan.Bateman at oracle.com Thu Feb 17 11:52:31 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Feb 2011 19:52:31 +0000 Subject: 6526860: (fc) FileChannel.position returns 0 when FileOutputStream opened in append mode Message-ID: <4D5D7C7F.90405@oracle.com> This one came up on the core-libs-dev mailing list last night [1]. When opened for append mode, FileChannel's position() will return 0 if invoked prior to writing to the file. It doesn't really make sense to use the position methods with files opened for append, the getChannel defined by the stream classes does specify that the position be the file size when opened for append so this should be fixed. The webrev with the changes to fix this are: http://cr.openjdk.java.net/~alanb/6526860/webrev/ Thanks, Alan. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-February/005920.html From forax at univ-mlv.fr Thu Feb 17 12:34:21 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 17 Feb 2011 21:34:21 +0100 Subject: 6526860: (fc) FileChannel.position returns 0 when FileOutputStream opened in append mode In-Reply-To: <4D5D7C7F.90405@oracle.com> References: <4D5D7C7F.90405@oracle.com> Message-ID: <4D5D864D.3000902@univ-mlv.fr> On 02/17/2011 08:52 PM, Alan Bateman wrote: > > This one came up on the core-libs-dev mailing list last night [1]. > When opened for append mode, FileChannel's position() will return 0 if > invoked prior to writing to the file. It doesn't really make sense to > use the position methods with files opened for append, the getChannel > defined by the stream classes does specify that the position be the > file size when opened for append so this should be fixed. The webrev > with the changes to fix this are: > > http://cr.openjdk.java.net/~alanb/6526860/webrev/ > > Thanks, > Alan. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-February/005920.html Looks good. R?mi From Alan.Bateman at oracle.com Sat Feb 19 08:01:57 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Feb 2011 16:01:57 +0000 Subject: 7020517: (fs) FileStore.equals returns true if both volumes have the same serial number Message-ID: <4D5FE975.7070105@oracle.com> One of our tests, test/java/nio/file/Basic.java, fails on Windows when there are multiple drives mapped to the same remote file system. The problem is that the equals/hashCode methods are based on the volume serial number, which probably wasn't a good choice. To fix this I've changed the methods to use the volume mount point. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7020517/webrev/ Thanks, Alan From Alan.Bateman at oracle.com Sun Feb 20 02:33:12 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 20 Feb 2011 10:33:12 +0000 Subject: 7020888: (file) Miscellaneous and trivial clean-ups (typos and opportunities to use suppressed exceptions) Message-ID: <4D60EDE8.60804@oracle.com> A small update to fix a few random typos in the javadoc and a broken link that slipped through. In addition it addresses (some) of the opportunities to record suppressed exceptions - these are places where try-with-resources isn't appropriate. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7020888/webrev/ Thanks, Alan. From Alan.Bateman at oracle.com Sun Feb 20 02:55:57 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 20 Feb 2011 10:55:57 +0000 Subject: Public Review Message-ID: <4D60F33D.8030408@oracle.com> As a FYI, we submitted a snapshot of the spec to the JCP as the Public Review of JSR-203. The snapshot is identical (except for a css fix) to what is in jdk7-b130. It's also archived on the project page [1] for easier browsing. -Alan. [1] http://openjdk.java.net/projects/nio/pr/docs/ From mike.duigou at oracle.com Sun Feb 20 05:57:14 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 20 Feb 2011 05:57:14 -0800 Subject: 7020888: (file) Miscellaneous and trivial clean-ups (typos and opportunities to use suppressed exceptions) In-Reply-To: <4D60EDE8.60804@oracle.com> References: <4D60EDE8.60804@oracle.com> Message-ID: All look good to me. Catching Throwable in SocketChannel does looks a little suspiciously broad. Other non-IOExceptions thrown in the context of the sc.close() would cause the original x to be lost. One can imagine an OutOfMemoryError being thrown especially if x is also an OME. Mike On Feb 20 2011, at 02:33 , Alan Bateman wrote: > > A small update to fix a few random typos in the javadoc and a broken link that slipped through. In addition it addresses (some) of the opportunities to record suppressed exceptions - these are places where try-with-resources isn't appropriate. The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/7020888/webrev/ > > Thanks, > Alan. From Alan.Bateman at oracle.com Sun Feb 20 08:45:11 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 20 Feb 2011 16:45:11 +0000 Subject: 7020888: (file) Miscellaneous and trivial clean-ups (typos and opportunities to use suppressed exceptions) In-Reply-To: References: <4D60EDE8.60804@oracle.com> Message-ID: <4D614517.8070609@oracle.com> Mike Duigou wrote: > All look good to me. Catching Throwable in SocketChannel does looks a > little suspiciously broad. Other non-IOExceptions thrown in the > context of the sc.close() would cause the original x to be lost. One > can imagine an OutOfMemoryError being thrown especially if x is also > an OME. > > Mike > Thanks Mike. On catching throwable, I think the more precise rethrow works well here and avoids needing to catch each of the possible runtime exceptions that connect can throw. In addition it gives us the chance to close the channel's socket in the event that an Error is thrown. On close throwing something other than IOException then you are right, this would supplant the exception, just not sure if it's worth worrying about. -Alan. From chris.hegarty at oracle.com Mon Feb 21 02:50:13 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 Feb 2011 10:50:13 +0000 Subject: 7020888: (file) Miscellaneous and trivial clean-ups (typos and opportunities to use suppressed exceptions) In-Reply-To: <4D614517.8070609@oracle.com> References: <4D60EDE8.60804@oracle.com> <4D614517.8070609@oracle.com> Message-ID: <4D624365.4000802@oracle.com> The changes look fine to me. I'm happy to see the close exceptions are no longer being ignored. -Chris. On 20/02/2011 16:45, Alan Bateman wrote: > Mike Duigou wrote: >> All look good to me. Catching Throwable in SocketChannel does looks a >> little suspiciously broad. Other non-IOExceptions thrown in the >> context of the sc.close() would cause the original x to be lost. One >> can imagine an OutOfMemoryError being thrown especially if x is also >> an OME. >> >> Mike >> > Thanks Mike. On catching throwable, I think the more precise rethrow > works well here and avoids needing to catch each of the possible runtime > exceptions that connect can throw. In addition it gives us the chance to > close the channel's socket in the event that an Error is thrown. On > close throwing something other than IOException then you are right, this > would supplant the exception, just not sure if it's worth worrying about. > > -Alan. From chris.hegarty at oracle.com Mon Feb 21 05:21:23 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 Feb 2011 13:21:23 +0000 Subject: 7020517: (fs) FileStore.equals returns true if both volumes have the same serial number In-Reply-To: <4D5FE975.7070105@oracle.com> References: <4D5FE975.7070105@oracle.com> Message-ID: <4D6266D3.2050302@oracle.com> I think the change look fine. equals() could compare the volInfo and volType also, but I guess these should be the same for identical roots, right? -Chris. On 19/02/2011 16:01, Alan Bateman wrote: > > One of our tests, test/java/nio/file/Basic.java, fails on Windows when > there are multiple drives mapped to the same remote file system. The > problem is that the equals/hashCode methods are based on the volume > serial number, which probably wasn't a good choice. To fix this I've > changed the methods to use the volume mount point. The webrev with the > changes is here: > http://cr.openjdk.java.net/~alanb/7020517/webrev/ > > Thanks, > Alan From Alan.Bateman at oracle.com Mon Feb 21 05:50:53 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Feb 2011 13:50:53 +0000 Subject: 7020517: (fs) FileStore.equals returns true if both volumes have the same serial number In-Reply-To: <4D6266D3.2050302@oracle.com> References: <4D5FE975.7070105@oracle.com> <4D6266D3.2050302@oracle.com> Message-ID: <4D626DBD.5020104@oracle.com> Chris Hegarty wrote: > I think the change look fine. > > equals() could compare the volInfo and volType also, but I guess these > should be the same for identical roots, right? > > -Chris. Thanks Chris. Yes, they should be the same for the same volume mount point. -Alan