Community
Participate
Working Groups
I20051130 To transparently support zip files on any file system, JDT Core would need an API that converts a URI to a java.io.File. This would be the same as IPath#toFile() if the resource is on the local file system, otherwise this would copy the resource on the local file system (in the metadata area ?), and return a java.io.File on this copy.
Target for M5.
I have released an initial API and implementation to HEAD. See IFileStore.toLocalFile. It has two main usage modes. 1) A file that store that already is a local file: store.toLocalFile(EFS.NONE, pm) -> returns null if the store is not a local file 2) A file in any store: store.toLocalFile(EFS.CACHE, pm) -> Creates a cached local copy of the file, regardless of what file system it is in. Not yet extensively tested...
I have fleshed out the implementation and added more test suites. This API is ready to be tried out.
Thanks for the new API, John. I have some questions/comments though: 1. According to you comment, EFS.CACHE will create a copy of the file even if it is local. However the spec suggest otherwise ("a cached representation of a file should be created if necessary"). 2. Is the copy updated if the file changes on the remote file system ? 3. This might not be necessary, but the spec could say where the copy is placed (I guess in the .metadata) and what the name of the java.io.File.
1. Thanks, I have fixed this comment. In my first prototype I would return either the local file or the cached file if CACHE was specified, but I think the client needs to know if they are dealing with a cached copy or the real file. 2. No, the copy is not updated. There is currently no mechanism for the file system to report changes, so this would require polling. The intent is that the the client calls toLocalFile every time they need it, and the implementation can optimize the case where the cached copy is the same as the backing file system. 3. I wanted to avoid this because I don't want to recreate the entire directory structure for the cached file. If there are multiple cached files with the same name I need to be generating different file names to avoid collision.
