News

Not much work has been done on JGenFile in the past month. The place where I work has moved to a location which takes me on average 80 minutes to get to. That combined with deadlines requiring me to work late means that I've had little spare time.

Most of JGenFile I'm happy with. However, I'm not too happy about how copying multiple files is done, especially if an error occurs. Right now, a PartialCopyException is thrown with details of which files were copied. I think this could be done better.

As for ZIP or FTP support, that will be coming later. I'm currently working on a toy console application that emulates MS-DOS (sort of). Once this is done I can use this for testing other file systems.

I'm so embarassed! All this time this web site would have looked like crap on everyone's computer but mine because I had a file: reference to a style sheet. Now the pages should look like they should look like.

Currently working on a simple console application for JGenFile. Will be useful for testing and as an example application.

I have researched ZIP files in Java, this will likely be what will be worked on next.

The FAQ has also been started..

JGenFile 1.0 alpha has been released. It contains the finished local file system implementation. Grab it from the downloads page.

Not long to go before the local file system implementation is finished. OperationHints have been added to allow hints such as whether progress observing is important to be added to operations. This works much like the RenderingHints of Java2D.

The ability to abort operations midway through their run has been added through an abort() method in the Operation interface. Only operations that can run for a long time, such as the recursive delete and copy operations, will have abort() support. The other operations in the local file system will simply ignore abort(), but since they don't take a long time to run anyway it wont matter.

I have decided not to support file locking in JGenFile. In my opinion it would hardly ever be used, especially since not all file systems are guarenteed to support file locking.

The local file system implementation is nearly finished. All that needs to be done is to finish the copy operation.

I have been going over whether file locking should be supported in JGenFile, and if so how it would be done. While local files would usually support locking, how would a file in a ZIP file or a file accessed through FTP be locked? One solution is to do as Sun do in the FileLock javadocs, and say that locks are merely advisory and there is no guarentee that they will do anything at all (it's not said in those exact words in the docs).

I have never used or needed file locking capabilities, and I am not sure how important they would be to users of JGenFile. It would be possible to get a lock on a channel in the local file system by attempting to cast a ByteChannel gotten from a FileAccessor to a FileChannel, or if it is an instance of WrappedByteChannel, attempt to cast the underlying channel. Yes it is a bit of a hack, but getting a lock on anything other than a file in the local file system would probably not be possibly anyway.

Still working on the local file system implementation. As it is being developed, I am finding little things in the base interfaces that need to be changed. I am also contemplating changing a few things to do with metadata access. The file system iteself should be able to have metadata, perhaps things like the server type for FTP file systems could go there. Also there needs to be a way to query what sort of metadata keys items in the file system support, so a rough idea can be obtained as to what columns in a GUI could be displayed for example.

Some operations such as deletion and copying need to have the ability for their progress to be monitored. This requires building a list of all items that are going to be deleted or copied beforehand which could cost some memory, especially if many thousands of files are involved. Perhaps I should add a way of telling the operation (or file system?) whether progress wants to be observed, or to generalize a bit further, a way of giving it hints on how it should process. I'm thinking something along the lines of Java2D's RenderingHints.

More work on the local file system implementation. It seems that every new operation I create and test, I find another reason why I am sick of the old java.io.File way of doing things. For example, try getting the roots in Windows through java.io.File.listRoots(). Then do a getName() on each file that is returned. Oh look, getName() returns an empty string.

I've decided that Windows network shares will NOT be supported through the local file system implementation for JGenFile. First reason, it violates the rule of that every file has an ancestor that is a root in the file system. Secondly, accessing files over the network should be done differently because of performance reasons. Anyway, network files aren't really local, are they?

The solution is to create a brand new file system that deals only with network shares. For now I'll allow the creation of items from references that refer to network shares, but this will be disabled later on when the Windows network share file system has been developed.

There's also the best solution which is also the most work. Create a file system that uses the SMB protocol to access the Windows shares. Would work with platforms other than Windows too. But that is not something that will happen soon, that is unless anyone is interested in lending a hand...

Work is progressing on the local file system implementation. Many generic operation classes are being developed as well, which will aid development of other implementations in the future.

The JGenFile interfaces are still undergoing minor changes. As I develop the local file system implementation, I find minor things that I want to change in the interfaces. So if you are browsing the CVS repository and decide to attempt to create your own file system implementation, be aware that the interfaces are still undergoing changes. I advise anyone that wants to start creating file system implementations to wait until the first beta comes out. This will occur when the local file system implementation is finished.

As you can see, the new JGenFile web pages are almost finished as well. Some pages such as Downloads are empty, since there is nothing to download yet.