From Alan.Bateman at Sun.COM Tue Sep 1 01:43:42 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 01 Sep 2009 09:43:42 +0100 Subject: suggestion for convenience method for BasicFileAttributes In-Reply-To: <18fbabce0908281130n57791e59u70d74ad770933e58@mail.gmail.com> References: <18fbabce0908281130n57791e59u70d74ad770933e58@mail.gmail.com> Message-ID: <4A9CDEBE.5030609@sun.com> Vince Bonfanti wrote: > A minor suggestion: as a convenience for provider implementors, it > seems that BasicFileAttributes could be declared abstract (rather than > an interface), and implement a method that looks something like below. > Otherwise, it seems that every provider implementor is going to have > to implement their own method that does exactly this (or something > similar). > > Vince > You are right that each provider will require code that is somewhat similar to this. The bigger question is how much should the runtime carry to make it easier for provider implementations (as the number of providers will be very small). For now, we don't have any base implementations in the spi package. -Alan. From Alan.Bateman at Sun.COM Tue Sep 1 01:46:04 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 01 Sep 2009 09:46:04 +0100 Subject: questions about mandatory/optional file attributes In-Reply-To: <18fbabce0908290829y33afc617sd37da5cbfc9b9efc@mail.gmail.com> References: <18fbabce0908290829y33afc617sd37da5cbfc9b9efc@mail.gmail.com> Message-ID: <4A9CDF4C.6070502@sun.com> Vince Bonfanti wrote: > : > > optional: lastModifiedTime(), lastAccessTime(), creationTime(), fileKey() > mandatory: isRegularFile(), isDirectory(), isSymbolicLink(), isOther(), size() > > Question #1: Is this list of mandatory/optional attributes correct? > Yes, although the isXXX methods are to query the file type, which doesn't have its own type in the API. In other words, the required attributes are the "file type" and the size. > Specifically, if my file system implementation does not support > symbolic links, am I supposed to return a boolean for > isSymbolicLink(), rather than throwing UnsupportedOperationException? > If your provider doesn't support symbolic links then isSymbolicLink will return false. If you have access to Windows XP or Windows Server 2003 then you try this out. > : > > Question #2: Does "supported" in the FileRef javadocs take the same > meaning as "mandatory" on the BasisFileAttributes javadocs? > Specifically, if my file system implementation does not support > symbolic links, am I supposed to return a Boolean from > FileRef.getAttribute( "isSymbolicLink" ), rather than returning null? > Yes, return Boolean.FALSE (not null, because the "file type" is a required attribute). We should probably add an additional column to the table in BasicFileAttributeView to make this clearer. > Finally, it appears there are no direct equivalents to > java.io.File.isDirectory(), isFile(), lastModified() or length() in > the java.nio.file.Path class. For example, the two most direct ways I > can find in NIO2 to do the equivalent of java.io.File.isDirectory() > are: > > Attributes.readBasicFileAttributes( myPath ).isDirectory(); > ((Boolean)myPath.readAttribute( "isDirectory" )).booleanValue(); > The basic attributes are read in bulk for performance reasons (as it is very common to require several attributes of the same file at around the same time). Luckily, many of the reasons to need to test the file type go away with the new API. However, if really needed, we can add helper methods to the Attributes class. -Alan. From Alan.Bateman at Sun.COM Tue Sep 1 05:10:29 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 01 Sep 2009 13:10:29 +0100 Subject: Should FileTime be serializable? In-Reply-To: <4A97949F.7060400@optrak.co.uk> References: <4A969A2F.6020508@optrak.co.uk> <4A96C1C1.3000802@sun.com> <4A97949F.7060400@optrak.co.uk> Message-ID: <4A9D0F35.9070506@sun.com> Mark Thornton wrote: > I was contemplating a simple backup application to test out the new > api and decided to serialize the file metadata. Some it (e.g. > UserPrincipal) needs to be translated to another form, but I did not > see any good reason why FileTime could not serialize itself. It's definitely worth consideration, with the String representation being a good candidate for its serialized form. Out of curiosity, what did you do for the UserPrincipals? Are you using the principal name? -Alan. From vbonfanti at gmail.com Tue Sep 1 05:52:56 2009 From: vbonfanti at gmail.com (Vince Bonfanti) Date: Tue, 1 Sep 2009 08:52:56 -0400 Subject: Fwd: questions about mandatory/optional file attributes In-Reply-To: <18fbabce0909010551v1af3c7e6x88d2e709264f4f47@mail.gmail.com> References: <18fbabce0908290829y33afc617sd37da5cbfc9b9efc@mail.gmail.com> <4A9CDF4C.6070502@sun.com> <18fbabce0909010551v1af3c7e6x88d2e709264f4f47@mail.gmail.com> Message-ID: <18fbabce0909010552p198e3414l7865f38ccdc5819c@mail.gmail.com> I understand about the bulk read of attributes. My point is, if my Path implementation is required to support the following, which must return a non-null Boolean: ? ?Path.getAttribute( "isDirectory" ); then it's trivial to provide an "isDirectory" method, which can be implemented entirely based on the above getAttribute call: ? ?public boolean isDirectory( LinkOption ... options ) { ? ? ? ?return ((Boolean)getAttribute( "isDirectory", options )).booleanValue(); ? ?} The same is true for all of the mandatory attributes. Therefore, I can't see any reason not to provide type-safe accessors for all of the mandatory attributes directly on the Path class (probably via the FileRef interface). Vince > >> Finally, it appears there are no direct equivalents to >> java.io.File.isDirectory(), isFile(), lastModified() or length() in >> the java.nio.file.Path class. For example, the two most direct ways I >> can find in NIO2 to do the equivalent of java.io.File.isDirectory() >> are: >> >> ? ?Attributes.readBasicFileAttributes( myPath ).isDirectory(); >> ? ?((Boolean)myPath.readAttribute( "isDirectory" )).booleanValue(); >> > > The basic attributes are read in bulk for performance reasons (as it is very > common to require several attributes of the same file at around the same > time). Luckily, many of the reasons to need to test the file type go away > with the new API. However, if really needed, we can add helper methods to > the Attributes class. > > -Alan. > From avinash.lakshman at gmail.com Sun Sep 6 09:05:03 2009 From: avinash.lakshman at gmail.com (Avinash Lakshman) Date: Sun, 6 Sep 2009 09:05:03 -0700 Subject: API's for monitoring disk activity Message-ID: Are there APIs to monitor disk related activity? An API based mechanism to get information provided by iostat. Any plans to add them going forward? Are there ways to obtain them today perhaps through some other library? Thanks Avinash -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090906/6545ce01/attachment.html From Alan.Bateman at Sun.COM Sun Sep 6 12:17:38 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 06 Sep 2009 20:17:38 +0100 Subject: API's for monitoring disk activity In-Reply-To: References: Message-ID: <4AA40AD2.5030806@sun.com> Avinash Lakshman wrote: > Are there APIs to monitor disk related activity? An API based > mechanism to get information provided by iostat. Any plans to add them > going forward? Are there ways to obtain them today perhaps through > some other library? There isn't anything in the management interface to the operating system (in java.lang.management) or in the platform extensions (com.sun.management). I'm not aware of any plans either but serviceability-dev would be the place to bring it up. For java.nio.file, it won't be too hard to expose the stats as FileStore attributes. Another option is to just simple open an InputStream to /proc/diskstats or /sys/blocks (where iostat reads the statistics for its output). -Alan. From avinash.lakshman at gmail.com Sun Sep 20 06:36:38 2009 From: avinash.lakshman at gmail.com (Avinash Lakshman) Date: Sun, 20 Sep 2009 06:36:38 -0700 Subject: FileSystem interface Message-ID: Hi All Could someone point me to any good usage of the FileSystem interface in NIO2? In short I am interested in learning how and where it can be useful. One thing I think it could be useful for is in building a virtual file system. But any examples would make me get my feet wet faster. THanks Avinash -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090920/778306e9/attachment.html From Alan.Bateman at Sun.COM Tue Sep 22 06:06:05 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 22 Sep 2009 14:06:05 +0100 Subject: FileSystem interface In-Reply-To: References: Message-ID: <4AB8CBBD.1070708@sun.com> Avinash Lakshman wrote: > Hi All > > Could someone point me to any good usage of the FileSystem interface > in NIO2? In short I am interested in learning how and where it can be > useful. One thing I think it could be useful for is in building a > virtual file system. But any examples would make me get my feet wet > faster. > > THanks > Avinash If you are looking for sample code then there is a "zip" provider (developed by Rajendra Gutupalli) that treats the contents of a zip/JAR file as a read-only file system. It's just a prototype and if someone gets time to work on it, it could included in jdk7 as a demo provider. You can grab the code from the nio repository (or the demo/nio/ZipFileSystem directory if you have one of the snapshot builds). It has a README here: http://hg.openjdk.java.net/nio/nio/jdk/file/tip/src/share/demo/nio/ZipFileSystem/README.txt There are many other ideas for file system providers. So what type of file system provider are you interested in? -Alan.