Community
Participate
Working Groups
Provide API for accessing richer set of file permissions. The new API should make possible settings permission for user, group and other where available. See bug 259643 for one case where the such API could be consumed.
If you don't implement this in a year or so, the point will be moot since Java 1.7 will come out and it has this capability already. So unless you really plan to address this soon, there isn't much point to this enhancement :)
Even when Java 7 is out a lot of projects will still be obligated to run on older JREs. That's the case of the Platform which runs on Java 1.4 now.
(In reply to comment #2) > Even when Java 7 is out a lot of projects will still be obligated to run on > older JREs. That's the case of the Platform which runs on Java 1.4 now. Yes, it will likely be several years before the platform itself can depend on Java 7. We could optionally forward to the Java 7 API if it is available (using reflection). If we did add such an API in EFS we would need to ensure it is compatible/consistent with the Java 7 API.
Created attachment 156230 [details] Patch_v01 I've added EFS.ATTRIBUTE_OWNER_READ, EFS.ATTRIBUTE_OWNER_WRITE, EFS.ATTRIBUTE_OWNER_EXECUTE and the same for group/others. Along with the fix for the original problem I reimplemented native libs as suggested by Martin on bug 259643, comment 42. The new version only wraps system calls and is consumed by OS specific UnixFileNatives class. All the units on Linux should pass, I've also checked the performance tests results. Right now more JNI calls is involved in completing a single operation but there is less reflection used from the JNI side. The most sensitive test I know - FileSystemPerformanceTest.testPutFileInfo() operates about 25% faster on my machine. The first tests (BenchFileStore) run about 25% slower but it might be related to Hot Sopt compiler kicking in as the results for new code are comparable if I increase the number of runs. Patch combines Mac and Unix sources into one file. Plus we get greater flexibility. For example one might enrich error message by checking errno after system call fails and now it's doable in Java. Also things like symlink and IMMUTABLE flag support (Mac) are decided in Java, no native rebuilds needed to turn it on/off. This new approach could be first rolled out only on one platform as the old lib is still supported. Please comment, keeping in mind the code is not final. Also it's not tested on Mac and lacks unit tests.
This sounds fantastic! I'll try to find some time for a first review.
Created attachment 156422 [details] Patch_v02 A few improvements and bug fixes.
Created attachment 156423 [details] Patch_v03 Minor fix.
Hardcoding values for the S_I* flags in Java is dangerous. They are not constant across unixes, so you will be forced to convert the mode flags returned from stat() calls to the values you have defined on architectures where they don't match.
(In reply to comment #8) I've checked the flags we consume on all the platforms we ship the library (AIX, Solaris, Linux, Mac OS X) and they are the same. Do you have some particular OS in mind?
Created attachment 156494 [details] Patch_v04 Minor update
For example USS has #define S_IFMT 0xFF000000 #define S_IFDIR 0x01000000 #define S_IFLNK 0x05000000
Also the fetchInfo code now seems to always require a stat() followed by lstat(). Before it used to only need an lstat() and this was followed by a stat() only if the target was a symbolic link.
Created attachment 156524 [details] Patch_v05 I've added initializing flags with native calls and some units.
Created attachment 156529 [details] Patch_v06 (In reply to comment #12) Fixed.
Created attachment 156532 [details] Lib for Mac OS X
The new patch has a problem. It calls String.getBytes() without specifying an encoding, but getflag() will only work if the encoding is ASCII.
Created attachment 156620 [details] Patch_v07 (In reply to comment #16) Thanks Dmitry, it's fixed. I've spotted it to, just didn't have to run tests yesterday. Anyway, it would work on virtually all systems as their defaults share lower 127 chars with ASCII.
Created attachment 156637 [details] Patch_v09 Javadoc update.
Patch_v09 and lib for Mac have been committed to HEAD.
Created attachment 156774 [details] Patch_v10 Changes for AIX PPC32, AIX PPC64, Linux x86 and Linux x86_64.
Created attachment 156776 [details] Libs for AIX PPC32, AIX PPC64, Linux x86 and Linux x86_64
Created attachment 156804 [details] Libs I've added Solaris SPARC and SPARCv9
Created attachment 156806 [details] Patch_v11 Makefile changes and build_info.txt updated for Solaris framgments.
All the changes have been released to HEAD. Marking as FIXED.
unfortunately, the fix creates a side effect (at least) on Mac with regard to FileStore.toLocalFile(EFS.CACHE, null) when applied to a read-only file store. A cached file that is created by the above method in .metadata/.plugins/org.eclipse.core.filesystem/filecache/ is marked as IMMUTABLE that prevents it's deletion at Eclipse/JavaVM shutdown. It also leads to an exception on the next Eclipse startup in FileCache.cleanOldCache() because the file in the old cache can not be deleted using java.io.File.delete(). I think that the FileCache implementation should take that files in file cache are not marked as immutable but only as read-only. Alternatively, the cache cleanup should be more robust and also delete immutable files. I have created a bug 323833 for the above issue.
This is the way it worked in 3.5. The fix maintained previous behavior.
