[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] [resources] Alias management
|
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
and the bugs
referenced from there.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
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
<Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
Hi
Terry,
I fully
agree.
-
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).
-
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.
-
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).
-
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
_______________________________________________
eclipse-incubator-e4-dev
mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
