Home » Modeling » EMF » URI#createFileURI() does not add the file scheme Windows?!
| URI#createFileURI() does not add the file scheme Windows?! [message #1371856] |
Wed, 21 May 2014 15:18  |
 Maarten Bezemer
Messages: 117
Registered: 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
- (adding a leading / is not required)
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 Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Maarten,
Comments below.
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...
> 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.
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
> (adding a leading / is not required)
>
> 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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| 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 Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Maartin,
Comments below.
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 08:59:57 GMT 2024
Powered by FUDForum. Page generated in 0.03752 seconds |
] 
Search
Help
Register
Login
Home
, so thanks again!