Abstract

The Java file I/O classes do not provide an API for manipulating many advanced attributes found in common file systems, including permissions support beyond read/write access and timestamps including creation time. This proposal is for an extension to the eclipse.core.resources API to add support for manipulating these attributes when they are available.

Background

This feature has been a long-standing request from many Linux developers who require the executable bit to be preserved on copying of projects and on checkout from CVS. An important example is shared object files on platforms where they must be set executable. As well, this problem occurs when unzipping or untarring files.

For more background, see Eclipse bugs 26100, 31303, 25387, and their many duplicates. For an existing workaround for shared libraries on HP-UX, see bug 20305.

Requirements and Design

Based on the above bug reports and investigation into the existing APIs, we decided on the following requirements and design decisions:

1. Must support the executable bit.
2. Must support both files and directories.
3. Need not be part of the copy/create functions, can be a separate call to 'fix' the permissions.
4. It must be OK for: setResourceAttributes(attributes); getResourceAttributes() != attributes
5. It should be extensible to support attributes we may require in the future.

Proposed API

We propose the following API:

1. An interface (IResourceAttributes) which defines get and set methods for all known useful file system attributes.
2. A default implementation (ResourceAttributes).
3. A function to set the attributes on a Resource (void setResourceAttributes(IResourceAttributes)).
4. A function to return the attributes of a Resource (IResourceAttributes getResourceAttributes()).
5. Native methods under CoreFileSystemLibrary to implement the get and set methods.

One of the advantages to this approach is its extensibility. A possible extension would be the addition of group or world permissions. By providing a default implementation class, we can replace methods with implementations that do something reasonable if group permissions become supported.

Proposed Attributes

We propose the following attributes be supported in the initial implementation:

1. Execute (Linux)

The following attributes may also be useful additions in the future.

1. Modification time (mentioned in bug 25387).

Example Implementation

This is a possible implementation of the proposal, contributed by Ben Konrath.

• o.e.core.resouce.patch
• o.e.core.resouce.linux.patch
• o.e.team.cvs.core.patch

Notes on the Implementation

The following are Ben's notes on his proposed implementation.

Will this obsolete/include the setreadonly stuff?

It could, but do we want it to? setReadOnly() is not platform specific and is suported by Java. It seems that the setReadOnly stuff uses the native implementation if it's available and if not it uses Java methods. What's the reason for this? I thought it would be better to use the Java version over the native. Maybe this is a speed issue? Dunno.

My opinion on this is that get/setAttributes should only be use for platform specific attributes that are not supported by Java. If the attributes become supported with a future version of Java, then a moving over to a pure Java solution should be considered.

The CVS plugin

When setting or getting the execute attribute, only the owner is set or checked for +x. This means that the cvs plugin may not check out files with the exact permissions as the file has on the server. The cvs plugin will always checkin files ugo+x. I am not sure if this is correct approach.

The RPM plugin

The RPM plugin will not be using this interface because there already exists a method copy(...) in FileSystemStore.java that will copy files with attributes. I still have to see if these will work with the RPM plugin. If they don't, the new ResourceAttributes would have to accommodate group and other for the RPM plugin to use it. This is because the RPM plugin needs to do a recursive copy preserving the all of permission bits.

compiling core.c

I had to compile core.c manually becuase I was getting some include errors. The commands I used were:

  gcc -fPIC -g -c -I/opt/j2sdk1.4.2_05/include/linux -I/opt/j2sdk1.4.2_05/include core.c -o core.o
  gcc -g -shared -Wl,-soname,libcore.so -o libcore_3_1_0.so core.o -lc

Some Questions

• I changed the version of the native library to be core_3_1_0. Is this correct?
• I'm not sure if I generated my JNI method stubs corectly. I ran 'javah -jni org.eclipse.core.internal.localstore.CoreFileSystemLibrary' from o.e.core.resources/bin. I then copied the method stubs to core.h in o.e.core.resources.linux. Is this okay?
• The file core.c does not have a license statement, only a copyright statement. I added a licence statement, is this ok?
• I added Red Hat as a contributor to the Files that I touched. Is this correct?

Todo

• check to see if the RPM plugin will work with the copy(...) method
• refactor CVS plugin to take advatage of the permissions support in ResourceSynceInfo.java
• make the CVS plugin display the correct perms in right mouse > properties > CVS. What should it display? IResourceAttributes makes the local version only u+x but it will write ugo+x when it checks stuff in.

Authors

This proposal can be mostly blamed on Ben Konrath, Douglas Pollock, and Billy Biggs.

ChangeLog

• 27 Sep 2004: Initial version posted.