Re: [dsdp-tm-dev] EFS support and file paths

[Radoslav Gerganov <r.gerganov@xxxxxxxxxx>]

Hi Martin,

Thank you for your comprehensive answer!
I am going to handle both path representations in my
getRemoteFileObject() and leave the FileService as is. About the
IRemotePath -- I think this is yet another proof that we need this API.
Unfortunately, as you have already said in bugzilla, this is a rather
big change so I will go with this workaround for now.

For the complete EFS support it turns out that there are some additional
things to be done like overriding getInputStream/getOuputStream from the
AbstractFileService. The other thing I have found is that my extension
of subsystemConfigurations should specify category "files" in order to
be considered an option for EFS.
Do you guys have any document on the wiki/mail list/newsgroup about what
an extender must do to support EFS in case of implementing a new file
subsystem?

Cheers,
Radoslav


Oberhuber, Martin wrote:
> Hello Radoslav,
> 
> Most of the EFS code is in RSEFileStoreImpl, and most of that
> code does not care about how your paths are represented because
> it just uses a getChild() / getParent() relationship on the 
> IRemoteFile / IHostFile objects.
> 
> The only place where an EFS URI needs to be converted is in
>    RSEFileSystem#getURI(URI)
> which in turn delegates to
>    RSEFileStore(String,String)
> 
> This information is then used in 
>   RSEFileStoreImpl.java line 312:
>   remoteFile = subSys.getRemoteFileObject(_store.getAbsolutePath(),
> monitor);
> 
> where you see that a normalized path is being passed into 
> the subsystem. So - looking at your specific WinCE Subsystem,
> I think that your
>    getRemoteFileObject(String, IProgressMonitor)
> method should be able to handle BOTH normalized AND native
> forms of pathes. I think that should be possible -- Windows
> NT also supports either / or \ characters. That will care 
> for the URI -> EFS -> Subsystem Conversion.
> 
> For converting the other way round, I think there is nothing
> you need to do since
>    RSEFileStore.toURI()
> delegates to
>    RSEFileSystem.getURIFor()
> which I think correctly handles backslashes already for you.
> 
> While this is a fix for now, I think that we should look at
> the issue again in the context of the IRemotePath idea
>    https://bugs.eclipse.org/bugs/show_bug.cgi?id=218947
> again.
> 
> 
> 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: dsdp-tm-dev-bounces@xxxxxxxxxxx 
>> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of 
>> Radoslav Gerganov
>> Sent: Freitag, 22. Februar 2008 10:55
>> To: Target Management developer discussions
>> Subject: [dsdp-tm-dev] EFS support and file paths
>>
>> Hi,
>>
>> As you may know I'm writing a new file subsystem (#214887) for Windows
>> CE devices and I have some question about the EFS support. It 
>> looks that
>> EFS uses / for file separator while my WinCEFileService uses \. I want
>> to support EFS in any case, so I have to make a decision how 
>> to convert
>> the file separators and where.
>>
>> In #218947 Martin has suggested me to use "normalized" paths
>> (/foo/bar/spam.txt) and to convert them to native paths in the
>> FileService. The disadvantage is that users will be forced to use
>> linux-style paths in RSE (e.g. for creating file filters) and 
>> they won't
>> be able to use file paths outside of RSE for 3rd party tools.
>>
>> The other option is to convert the EFS paths to WinCE paths 
>> in my custom
>> WinCEFileServiceSubSytem. Can you point out any drawbacks of 
>> doing this?
>>
>> Thanks,
>> Radoslav Gerganov
>> _______________________________________________
>> dsdp-tm-dev mailing list
>> dsdp-tm-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>>
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> 
>