Hi Terry,
after more investigations, I believe that we should make the following
additions
to EFS:
*
String IFileStore#getCanonicalPath() throws CoreException
Will be necessary for IWorkspace.findFilesForLocation() if a
filesystem has symlinks.
If we want to introduce this in a fully compatible fashion, we
could also think about doing
IFileInfo#getStringAttribute(EFS.ATTRIBUTE_CANONICAL_PATH)
instead.
*
Object IFileInfo#fileKey()
A unique key identifying a file (e.g. on UNIX: Device ID + INode
number), or null if not available.
Can be used to determine with least effort whether two files are
the same, e.g. in order to
avoid cycles due to symbolic links when walking a file tree.
I've had that idea for a very
long time, and seeing it in JSR203 confirms for me that this is
worthwhile.
*
boolean IFileStore#isSameFile(IFileStore other) throws
CoreException
Also for checking link cycles and fixing issues with case
(in)sensitive file names.
More efficient than doing getCanonicalPath() on both file
stores... we might
acutally get away without this API since it's only about
efficiency.
*
boolean IFileInfo#getAttribute(EFS.ATTRIBUTE_SPECIAL_FILE)
For files that are neither a directory nor regular file nor
symbolic link (such as named
pipes, Unix domain sockets, or devices). These should get
special treatment.
*
boolean IFileStore#createSymbolicLink(String linkTarget, int
options, IProgressMonitor mon) throws CoreException
I think we need this for properly importing from file system /
tar archive into workspace.
I'm not so sure any more if we really need more asynchronous support.
What we might need,
though, is some API around manipulation of file system paths (resolving,
concatenating, stripping)
as well as some Monitoring API.
> * IFileStore.isAlias() -- much lighter weight than getting the
canonical path, only returns true if last segment is aliased
I think we have this already, with
boolean IFileInfo#getAttribute(EFS.ATTRIBUTE_SYMLINK)
I'm not exactly sure how we could be dealing with hard links -- the
fileKey() and
isSameFile() methods could help here, or we treat all kinds of aliases
with
ATTRIBUTE_SYMLINK... I'm not sure. Hard links are also the same concept
as what McQ mentioned on system/i -- the very same file referenced in
both
a case sensitive and case insensitive manner by different file paths.
I think that your other requirements are basically covered by
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233939#c9
and the bugs referenced from there.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Terry
Parker
Sent: Wednesday, October 08, 2008 8:42 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] [resources] Alias
management
Hi Martin,
Thanks for your comments. Keeping the file system layer
stateless is the right approach. I think the following additions would
be sufficient:
* IFileStore.getCanonicalPath()
* IFileStore.isAlias() -- much lighter weight than getting the
canonical path, only returns true if last segment is aliased
A big concern I have is that if the resource layer solely adds
getCanonicalPath() to existing methods, it won't get invoked
consistently. Perhaps having {IWorkspace,IProject}.findResource(String
absolutePath) API calls as the primary/only way to convert a path string
to a resource would provide the consistency we need.
Here are some scenarios for which we will want aliasing to work
correctly:
A) The file "/real/myfile.cc" is symlinked by
"/project_alias/myfile.cc". Desired behavior:
* When a debugger returns the path "/real/myfile.cc", the debug
framework opens the resource associated with project_alias, not a
separate resource outside the workspace
B) "/project/external_lib/headers" is symlinked to the folder
"/project/external_lib/v1234/src/headers".
"/project/external_lib/v1234/src/headers/file_with_syntax_error.h" fails
to compile. Desired behavior:
* Clicking on a console hyperlink or a Problems pane item for
the error opens the workspace-mapped resource. (This is no different
from A, but illustrates that symlinks can occur in any segment in a
path, not just the end segment.)
C) "/project1/external_lib/headers" and
"/project2/external_lib/headers" are both symlinked to the folder
"/project1/external_lib/v1234/src/headers". On a build of project1,
code in an #ifdef in "/project/external_lib/v1234/src/headers/header.h"
fails to compile. Desired behavior:
* You get two different editor panes when opening
"/project1/external_lib/headers/header.h" and
"/project1/external_lib/headers/header.h", since they may be used with
different compilation directives, which would affect their display
* Clicking on a console hyperlink or a problems pane item for
the error opens the workspace-mapped resource for the project1 version
of the file
* Editing the "header.h" file updates both editors in concert
--Terry
On Tue, Oct 7, 2008 at 10:31 AM, Oberhuber, Martin
<[EMAIL PROTECTED]> wrote:
Hi Terry,
I fully agree.
1.
Create / Modify Aliases. I also don't see a need
for creating / modifying file system links from Eclipse. There should be
support for visualizing them, though (which is easy to add in Eclipse
3.5 already).
2.
Consistent normalized path support. Agree. We'll
need IFileStore#getCanonicalPath() on the EFS API, and we'll need smart
algorithms on the Resource / Refresh / Compare code to avoid using
getCanonicalPath() where possible, in order to maintain good
performance. In other words, query the canonical path only when we come
across an FS link, but construct the path ourselves for "regular" files
and folders. The Workspace Tree will need some redesign to understand
links "moving around" its structure.
3.
Serve up both normalized and non-normalized path
strings. Yes, though I think this is probably more relevant for resource
objects than for filesystem objects -- the FS layer does exactly that
with a getCanonicalPath() API already, but since FS must be stateless it
will be expensive. On the Resource layer, we can add state (caching) to
make it faster.
* the non-normalized path is how the client /
user originally referred to a resource, and
* the normalized path is its normalized variant
(can be computed from the workspace tree).
4.
Support team providers for VCSs that can check
in symlinks. I'm not sure if that is required. Assuming that foo/bar is
a symlink, doing a "checkin foo/bar" will check in the symlink as
needed. To me, it seems that all we need to make sure is that we don't
instruct the VCS to check in the same file twice just because we
approach a given (normalized) file through multiple different
(non-normalized) paths. This should be possible through an improved
alias-aware Workspace Tree.
I think that if we are careful, there is some potential
to even add proper Alias Management in Eclipse 3.5 already, though that
needs a lot more investigation. What I would propose, is starting that
work soon in order to see whether we can apply it to Galileo already or
whether it requires more radical change that would make it impossible in
3.5.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind
River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
