Eclipse Community Forums Forum Search:

Home » Modeling » EMF » URI#createFileURI() does not add the file scheme Windows?!
URI#createFileURI() does not add the file scheme Windows?! Wed, 21 May 2014 15:18
 Maarten BezemerMessages: 117Registered: February 2012 Senior Member
Hello,

I have some problems with URI#createFileURI() under Windows, its result lacks the 'file' scheme. The methods javaDocs states:

Quote:
The <code>pathName</code> is converted into an appropriate form, as follows: platform specific path separators are converted to /; the path is encoded; and a "file" scheme and, if missing, a leading /, are added to an absolute path. The result is then parsed using {@link #createURI(String) createURI}.

Code snippet that shows the problem (part of my test suite, that is used to test the IFile to uRI conversion of non-existing files):
IFile nonExistingFile = createEmptyFile(project, "test.txt"); // Custom method that creates a file and returns the IFile instance
deleteResource(nonExistingFile); // Custom method that deletes the file

URI result = URI.createFileURI(nonExistingFile.getFullPath().toOSString()); // In the real secanario, this is part of a utility method that I want to test

In this example nonExistingFile is "L/sample/test.txt", the returned OSString is "\\sample\\test.txt" and the final result is "/sample/text.txt".

When looking at the (final) result one can see that

• the path specific separators are properly converted
• (encoding is not required)
• the file scheme is missing

Comapred to the JavaDoc, the file scheme is not set/missing...

Note that the file scheme is added under Linux (I did not test Mac OS).

Is this a bug, or am I doing something wrong to be sure that this particular piece of code is working on all platforms?

Thanks,
Maarten
Re: URI#createFileURI() does not add the file scheme Windows?! [message #1372125 is a reply to message #1371856] Wed, 21 May 2014 17:48
 Ed MerksMessages: 26756Registered: July 2009 Senior Member
Maarten,

On 21/05/2014 5:18 PM, Maarten Bezemer wrote:
> Hello,
>
> I have some problems with URI#createFileURI() under Windows, its
> result lacks the 'file' scheme.
Likely that depends on whether the file path is absolute, keeping in
mind that an absolute file file path on Windows includes a device...
>
> Quote:
>> The <code>pathName</code> is converted into an appropriate form, as
>> follows: platform specific path separators are converted to /; the
>> path is encoded; and a "file" scheme and, if missing, a leading /,
>> are added to an absolute path.
Yes, not specifically it's talking about an absolute path....
>> The result is then parsed using {@link #createURI(String) createURI}.
>
>
> Code snippet that shows the problem (part of my test suite, that is
> used to test the IFile to uRI conversion of non-existing files):
>
> IFile nonExistingFile = createEmptyFile(project, "test.txt"); //
> Custom method that creates a file and returns the IFile instance
> deleteResource(nonExistingFile); // Custom method that deletes the file
So this isn't looking like an absolute path...
>
> URI result =
> URI.createFileURI(nonExistingFile.getFullPath().toOSString()); // In
> the real secanario, this is part of a utility method that I want to test
>
> In this example nonExistingFile is "L/sample/test.txt", the returned
> OSString is "\\sample\\test.txt" and the final result is
> "/sample/text.txt".
That's a path relative to the current device/drive...
>
> When looking at the (final) result one can see that
>
> the path specific separators are properly converted
> (encoding is not required)
> the file scheme is missing
>
> Comapred to the JavaDoc, the file scheme is not set/missing...
>
> Note that the file scheme is added under Linux (I did not test Mac OS).
On Linux a path like /foo/bar is absolute, on windows, a path like
\foo\bar is not an absolute path, it's a path relative to the current
device...
>
> Is this a bug, or am I doing something wrong to be sure that this
> particular piece of code is working on all platforms?
Yes, when in doubt, use new File(<path>).getAbsolutePath() and then
you're sure it's an absolute path and then you're sure you'll get an
absolute URI...
>
> Thanks,
> Maarten
Re: URI#createFileURI() does not add the file scheme Windows?! [message #1372296 is a reply to message #1372125] Wed, 21 May 2014 19:30
 Maarten BezemerMessages: 117Registered: February 2012 Senior Member
So basically it boils down to this code returning an absolute or relative path depending on the platform/OS..?

Quote:
IFile nonExistingFile = createWorksaceFile(project, filename);
// Delete the workspace file
String fileStr = nonExistingFile.getFullPath().toOSString();

In this example I would expect bothh to be relative paths (to the workspace). So it seems that Linux is messing up and not Windows? (As it is return an (incorrect) absolute path)
Unless, it is expected to result in an absolute path, since the file does not exists (anymore) and therefore is not workspace specific anymore. In that case the Windows result should have a deivce added to make the result absolute.

Either way it seems strange that depending on the platform the result in absolute or relative...

I guess, I'll feed 'fileStr' through jave.io.File to make make sure it is absolute and have a platform independence again.

Regards,
Maarten
Re: URI#createFileURI() does not add the file scheme Windows?! [message #1373149 is a reply to message #1372296] Thu, 22 May 2014 04:07
 Ed MerksMessages: 26756Registered: July 2009 Senior Member
Maartin,

On 21/05/2014 9:30 PM, Maarten Bezemer wrote:
> So basically it boils down to this code returning an absolute or
> relative path depending on the platform/OS..?
>
> Quote:
>> IFile nonExistingFile = createWorksaceFile(project, filename);
>> // Delete the workspace file
>> String fileStr = nonExistingFile.getFullPath().toOSString();
>
>
> In this example I would expect bothh to be relative paths (to the
> workspace).
This example basically seems nonsensical...
> So it seems that Linux is messing up and not Windows?
No.
> (As it is return an (incorrect) absolute path)
No, you're messing up concepts (which I should have noticed in your
first post). The full path of an IFile is a workspace relative path.
Calling toOSString returns you something that's meaningless if
interpretted as a file system path in the OS's file system.
> Unless, it is expected to result in an absolute path, since the file
> does not exists (anymore) and therefore is not workspace specific anymore.
No, you're confusing the path returned by getFullPath (a logical
workspace path) with what's returned by
org.eclipse.core.resources.IResource.getLocation().
> In that case the Windows result should have a deivce added to make the
> result absolute.
No, you shouldn't confuse a path that represents the logical path in the
workspace, with the physical location of the IFile, nor should you
assume the IFile is necessarily in the file system at all because via
EFS it's possible for it to be backed by something else, i.e., see
org.eclipse.core.resources.IResource.getLocationURI().
>
> Either way it seems strange that depending on the platform the result
> in absolute or relative...
>
> I guess, I'll feed 'fileStr' through jave.io.File to make make sure it
> is absolute and have a platform independence again.
No, if you want a URI that refers to the IFile itself you should read:
http://wiki.eclipse.org/EMF/FAQ#How_do_I_map_between_an_EMF_Resource_and_an_Eclipse_IFile.3F
>
> Regards,
> Maarten
Re: URI#createFileURI() does not add the file scheme Windows?! [message #1376276 is a reply to message #1373149] Fri, 23 May 2014 10:38
 Maarten BezemerMessages: 117Registered: February 2012 Senior Member
Ed,

The core issue was that I was wrongly assuming that getFullPath() returns an absolute (full) path.
Replacing it with getLocation() works much better in my case, as it actually required to obtain/use absolute paths (in the code that was using the tested methods).

I found some other similar issues in my code as well , so thanks again!

Regards,
Maarten

[Updated on: Fri, 23 May 2014 13:14]

Report message to a moderator

Goto Forum:

Current Time: Mon Aug 03 08:54:39 GMT 2015