RE: [eclipse-incubator-e4-dev] [resources]File systemlayer requirements

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hi Szymon,

> I would expect all implementations to work in the same way.
> So it should be possible to implement the new EFS API using 
> just java.io, right?

Well you'd have a hard time finding out ACL's of a file or
even UNIX group ownership using just java.io.File -- you'd
either need some JNI code for that, or call system utilities:
   Runtime.getRuntime().exec("ls -l "+filePath);

I think that the API should be driven by what we think we
need. That being said, implementations may be allowed not
to provide certain features or not. Permission/Owner/ACL
support may simply not be available on a java.io.File based
implementation. Already now, 
   IFileSystem#attributes()
returns the features of a particular EFS implementation. 

>From  my current point of view, the minimum that we
need in addition to current EFS is

   getCanonicalPath()
      // for symbolic link alias mgmt
   mkSymLink()
      // for creating symbolic link

I think that there is a need for mkSymLink when importing
existing projects (which may include symlinks) from file 
system or TAR archive into the workspace. Users expect the
right structures to be created in the workspace.

> we could consider having file system notifications in EFS, 
> instead of RefreshProvider API available only on the 
> resource layer.

Yes, this sounds like a good suggestion.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -----Original Message-----
> From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx 
> [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On 
> Behalf Of Szymon Brandys
> Sent: Wednesday, October 15, 2008 2:03 PM
> To: E4 developer list
> Subject: RE: [eclipse-incubator-e4-dev] [resources]File 
> systemlayer requirements
> 
> >> My idea was that we could come up with a beefed up EFS API that
> >> provides access to features provided by JSR203, and learn from
> >> its API decisions (actually some of them are in EFS already,
> >> such as atomic copyTo() / moveTo() operations, or throwing
> >> exceptions rather than returning boolean in case of failure).
> 
> >> Because then we can have multiple implementations of the EFS API --
> >> ranging from most basic ones (based on java.io.File) over medium
> >> versatile ones (based on the current native liblocalfile) upto
> >> a plugin based on Java7, which would likely have more features
> >> but only run on a Java7 JRE only.
> 
> I would expect all implementations to work in the same way.
> So it should be possible to implement the new EFS API using 
> just java.io,
> right?
> 
> For me interesting part of JSR208 is WatchService API. I think that we
> could
> consider having file system notifications in EFS, instead of
> RefreshProvider API
> available only on the resource layer.
> 
> I hope it makes sense.
> --
> Szymon Brandys
> 
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>