Java 7 - nio.2

Project:JNode FS
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:active
Description

I have an encrypted NTFS image here, and when you try to read the files, it throws IOException.

This makes it difficult to determine if the file was encrypted, as IOException is thrown for all sorts of other reasons.

I would like a way to determine this condition, and have two alternative proposals:

1. When you try to read the encrypted file, throw some exception more specific than IOException so that it can be caught.

2. Offer API on FSEntry or some other tagging interface to allow determining if the file is encrypted before trying to read from it.

The second option seems to be the better of the two as exception handling comes with an overhead and if it's possible to determine this sort of thing up-front, you can avoid it. So assuming that is desirable to others, I am proposing the following simple API:

interface FSEncryptable {
  boolean isEncrypted();
}

If an FSEntry (it will typically be an FSFile, I think, unless any filesystems support encrypted directories) is an instance of FSEncryptable, you can cast to it to determine if the entry is encrypted before reading from the file.

#1

Submitted by the_felis_leo on Fri, 03/04/2011 - 09:34.
Title:When encryption is encountered in file systems, do something other than just throw IOException » Java 7 - nio.2

((Sorry, I've not taken time to look at jnode FS api...))

Some ideas:

extends {{@since 1.7} Enum java.nio.file.AccessMode} with ENCRYPTED
(But not a portable way)

overrides {{@since 1.7} java.nio.file.Files#getAttribute(Path, String, LinkOption...)
implements {{@since 1.7} java.nio.file.attribute.FileAttributeView}
(Prefered solution.)

overrides {{@since 1.0} java.nio.file#canRead()}: return false if encrypted

-- Edit --
Maybe Jnode FS api should migrate to Java7 NIO.2

OpendJDK 7 is available, but seems to be License disagreements...
Other else, beta patch may be usable.

#2

Submitted by Daniel Noll on Mon, 04/04/2011 - 05:45.

Funnily enough, when I was coming through to implement the additional file times method, someone on the JNode project said not to rely on NIO2 because it wasn't out yet.

I guess it's closer today, but it's still not final. That may not be an issue, if it doesn't change much from now on.

I checked the Javadoc for FileAttributeView and didn't find anything related to encryption, so I'm thinking that it would have to be a new implementation specific to JNode. Additionally, as far as I know, NIO2 isn't anywhere in the FS API yet. So this would need to be done as a prerequisite, I assume?

#3

Submitted by Peter on Mon, 04/04/2011 - 18:02.

Well, I think having "stubs" in the code that are "nio2-ready" is ok, too. So implementing it in a way that might play well together with nio2 in the future (so nio2 will not be a real prerequisite).

Anyway, I'm a bit confused as to what this "encrypted file" means. I'm a linux user only, so I'm not aware of these ntfs specifics. But I'd assume that the encryption is an "OS feature" rather than a "userspace feature". So I'm wondering if there's a reason at all to export the encryption status to the JavaAPI (i.e. userspace) or if this is something that should be handled by the OS (In an API sense the difference would be, if we had to implement it in our jnode.fs stuff or in java.io, too)?

#4

Submitted by the_felis_leo on Wed, 04/06/2011 - 08:00.

"encrypted file" are an NTFS OS feature.
Encryption should be transparent for end user application.
Windows automatically manage user certificates.

Meanwhile exposing attribute is need for advanced programs,
like file or backup manager.

Also a user accessing an encrypted file without credentials
could be asked to provide them,
either by an auxiliary login or by certificates.
(This could be handle by file selector dialog box)

#5

Submitted by Daniel Noll on Mon, 06/25/2012 - 23:13.

Now that NIO2 is out, has JNode made any movement towards supporting it, or is there at least some idea of how it will fit into the existing FS API? (We only use the FS API directly so full support for the running OS isn't something we particularly need.)

If I could get an idea of how it's going to fit in, I could possibly convert the existing file times APIs over as a starting point.

#6

Submitted by galatnm on Tue, 06/26/2012 - 20:44.

I try to use NIO for cpCommand to have faster copy but i have null pointer exception for the moment. Concerning support of JDK7 and NIO2, i could be a good thing but i have no idea on how to use openjdk 7 implementation.