Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 184534 - LocalFileSystem should query available attributes from native lib
Summary: LocalFileSystem should query available attributes from native lib
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.3   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 3.3 RC1   Edit
Assignee: John Arthorne CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-27 19:19 EDT by Martin Oberhuber CLA
Modified: 2008-10-06 21:59 EDT (History)
1 user (show)

See Also:
dj.houghton: review+


Attachments
Patch for reading liblocalfile capabilities from native, with fallback (7.46 KB, patch)
2007-05-02 05:41 EDT, Martin Oberhuber CLA
john.arthorne: iplog+
Details | Diff
Patch for optimized build in UNIX Makefiles (2.00 KB, patch)
2007-05-08 04:59 EDT, Martin Oberhuber CLA
john.arthorne: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2007-04-27 19:19:21 EDT
+++ This bug was initially created as a clone of Bug #184433 +++

The LocalFileSystem currently tries to guess what attributes are supported based on a priori knowledge of what the known native libraries support. This does not account for the fact that 3rd parties can add more fragments for native libraries on other architectures, that may support different attributes.

The native library is the instance which knows best what attributes can be supported. Therefore, it should be consulted when computing attributes. The corresponding native library entry point can be made optional, with a fallback to the current guessing if it is not available (and the library is thus considered "old"). Newer libraries should be compiled with the new entry point to allow them announce their capabilities.

The problem became evident when gradually adding more symlink-enabled native libs for bug 170317 -- with each new native lib, the Java code in LocalFileSystem had to be changed.

Bug 184433 has a patch attached that fixes the issue already. This patch should be applied (with the bug number replaced by this one in the Copyright comments).
Comment 1 Martin Oberhuber CLA 2007-05-02 05:26:33 EDT
This bug is related to potential contribution of symlink-enabled liblocalfile for Solaris x86, AIX or HP-UX. I made notes about this in 
  * bug 170544 comment 23 (for Solaris x86)
  * bug 169819 comment 10 (for HP-UX)
  * bug 176470 comment 2 (for AIX).

For more general, oder notes about recompiling liblocalfile on other architectures, see bug 12358 (includes interesting general notes) and bug 111243 (more recent notes).
Comment 2 Martin Oberhuber CLA 2007-05-02 05:41:14 EDT
Created attachment 65583 [details]
Patch for reading liblocalfile capabilities from native, with fallback

Attached is a patch for reading the capabilities of a liblocalfile right from the native library. The code has a fallback to the current "well known" method in case the native lib does not have the autodetect capability built in so it is 100% backward compatible.

This is just a resubmission of the existing patch from bug 184433, with the bug number in the copyright comments updated.

Legal Message: I, Martin Oberhuber, declare that I developed attached code from
scratch, without referencing any 3rd party materials except material licensed
under the EPL. I am authorized by my employer, Wind River Systems Inc., to make
this contribution under the EPL.
Comment 3 John Arthorne CLA 2007-05-02 15:06:57 EDT
Target for release in RC1. The patch looks good but I don't want to release it this close to M7.  Releasing in RC1 will give us time to recompile the natives on as many platforms as possible.
Comment 4 Martin Oberhuber CLA 2007-05-03 05:28:54 EDT
Thanks!

On a side note (not really important), recompiling is not really neccessary since the fallback in case of finding an "old" native lib is exactly the current behavior. 

Recompiling just makes sense for native libraries for "new" architectures that are not registered as providing symbolic link support yet. 

For those already registered, recompiling just makes them "play slightly more nicely" with the JVM since it avoids the UnsatisfiedLinkError exception. Only if ALL native libs known to the current "old style mechanism" are recompiled, this will enable us to remove slightly more code from the FileSystem#attributes() method. (And it makes the CVS code base more clean if compiled libraries in HEAD match the code that is in HEAD).
Comment 5 Martin Oberhuber CLA 2007-05-08 04:58:40 EDT
In case we recompile (some) native libraries with this patch for RC1, we should perhaps consider compiling with -O -s (optimized, strip debug info) instead of -g in order to save some unnecessary bits.

Debugging the sharedlibs is not useful anyways - and I just learned that the Equinox Launcher is also compiled with -O -s. In my testing, these switches reduce the size of the shared library from 35K to 10K.
Comment 6 Martin Oberhuber CLA 2007-05-08 04:59:50 EDT
Created attachment 66264 [details]
Patch for optimized build in UNIX Makefiles

Attached patch changes the UNIX (Linux, Solaris) Makefiles to build optimized (-O -s) by default. Also, for Solaris the native compiler (cc) is now the default but can be overridden on the commandline to use gcc instead.
Comment 7 John Arthorne CLA 2007-05-10 09:58:40 EDT
I have released your patch, and also updated and recompiled the Windows native to implement the attributes native. I have also released your Makefile changes. Thanks for your help as usual.