Community
Participate
Working Groups
EFS is a great addition to Eclipse, it provides the base technology for remote projects / remote build support like outlined e.g. here: http://wiki.eclipse.org/index.php/PTP/designs/remote/cdt as well as in some commercial additions to Eclipse. Through bug 170317, symbolic link support has been added to EFS, but the int/String based properties used for symbolic link targets limit this design to properties that are well-known and predefined by the Platform. It is not extensible and blocks EFS from future improvements or vendor enhancements. An improved API is required for setting file properties in order to make EFS fit for the future. Files on remote file systems often very special properties that are important to know for the user. These can range from the owner of a file to file encodings and content type (see bug 106176 comment 34). File system providers know how to obtain these properties easily, and should be able to provide this information to upper levels through a common API. Adding generic properties to IFileInfo object seems the right approach for this. We have a concrete need for generic remote file system properties in Target Management / RSE (see bug 170317 comment 23). Supporting properties in EFS in a generic manner allows to write generic code for presenting these properties in the UI (bug 165171), or code to copy files between file systems preserving properties, provided that both file systems support a given property (bug 166473). Having this in EFS would allow us to allow RSE clients make file system contributions through EFS rather than our old, grown-over-time IFileService API. Generic properties will also help to wrap existing file system libraries like Jakarta Commons / VFS in a better way (bug 106176 comment 9, and bug 106176 comment 20).
Created attachment 60092 [details] Patch to add generic file properties to EFS Attached patch provides generic file properties for EFS. Some basic design considerations: * Existing int/String API is fully preserved but marked deprecated. The patch should be fully compatible with Eclipse 3.3M5. * Properties are associated with IFileInfo rather than IFileStore since clients may choose to read properties or not need them for other applications. Existing IFileStore.fetchInfo() implementations work very well for this. An improved implementation could define an options flag for fetchInfo() to specify whether just the "quick and easy" properties should be retrieved (similar to SHALLOW) or also "more time consuming ones" (similar to DEEP). Also, IFileStore.equals() should depend on the file store's name alone but not any properties. * For the property key, a new interface (IFilePropertyType) is introduced. This allows for equals() and hashCode() implementations, and provides meta-info that can be extended in the future. The meta-info includes type information, which is currently only for informational purpose and not being checked in the providers. * Rather than limiting FileInfo not to be subclassed by clients, this is now allowed because the file system providers are the only ones who know how their file information can be stored most efficiently. They are now allowed to derive from FileInfo in order to provide their special implementation. By allowing extenders to register their own file properties which are identified by a String (reverse DNS notation recommended), it is possible for anyone to register their own file properties. Plus, file system providers can be compatble with each other just by supporting file properties with the same ID and type even if they do not have to share a common interface.
Just wondering, do you want to keep the int-based EFS Properties for M6 or get rid of them again? Although I like my attached patch a lot - after a long talk I had with Michael Valenta at EclipseCon, I'm easy with anything, since there's good arguments for all alternatives. * Keeping the int-based Properties API would allow passing the symbolic link target (which I don't consider particularly helpful) or a unique file ID that could be derived from UNIX inode numbers (which might be more helpful as a high-performance alternative for File.getCanonicalPath() e.g. in bug 105554). * On the other hand, I consider the int-based properties still somewhat awkward in case one wants to extend them in the future... but even that could be solved with a utility class that generates new unique integer numbers for arbitrary passed-in IDs. * For the concrete case of symbolic links, it's more important to know that something actually is a symbolic link (boolean attribute) than knowing the link target; since properly resolving a link target is only possible on the concrete target filesystem, it's not of much value except informational. In any case, providers who think they _have to_ do special properties can always derive from FileInfo and do their own thing (yes I know the API discourages that, but it's not impossible). So even though I like my attached generic patch here a lot, I'm fine with not using it and either keeping the int-based properties or getting rid of them and staying with boolean-only properties.
PS In case time is an issue, it might be an option to deprecate the get/setStringAttribute() API for M6 and decide on getting rid of it or keeping it for M7?
The API will be frozen for M6 - deleting API in M7 is not possible. I am inclined to keep the API we have.
Here is another suggestion for M6: Keep the current functionality, but move it out of API and into internal packages. Affected items would be: package org.eclipse.core.internal.filesystem; public interface IFileInfo2 extends IFileInfo { public static final int ATTRIBUTE_LINK_TARGET = 1 << 6; public abstract String getStringAttribute(int attribute); } package org.eclipse.core.internal.filesystem.local; public class LocalFileInfo extends FileInfo implements IFileInfo2 { public String getStringAttribute(int attribute) { /* ... */ } public void setStringAttribute(int attribute, String value) { /* ... */ } } So we could still use and experiment with the functionality, keep current native libraries as they are, but have it out of API for 3.3. People who think they need it could use it from the internal package. If you are interested, I could put together a patch for this.
I'm working on the EFS-editor and I would like to see the J2EE-Web like context idea. java.lang.Object getAttribute(java.lang.String name); java.util.Enumeration getAttributeNames(); void setAttribute(java.lang.String name,java.lang.Object o); void removeAttribute(java.lang.String name); I realy need them for the editor so a user can select what he wishes to see, and the EFS provider can give the correct attributes. I realy hope this will be adapted. Please select for the attributes values Object in stead of a String.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
