[
https://issues.apache.org/jira/browse/VFS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497351#comment-13497351
]
Joerg Schaible commented on VFS-443:
------------------------------------
1/ I am -1 to make getLocalFile() public. The internal File instance was always
meant to be a lazy object that is not necessarily created.
2/ the comment lies for Unix ;-)
{noformat}
$ touch \?.txt
$ ls *.txt
?.txt
{noformat}
and of course can a file in Unix also have characters '\\', ':', '\'', or ...
(well, as long as it does not save it into FAT).
3/ For me it seems that VFS does not really separate between URL and URI. E.g.
an URL cannot contain a space, while it is valid for an URI. Therefore, if
something like FileObject.getURL() returns a URL, it should always be possible
to create a URI from it - and this is not limited to file URLs only. Basically
it is now at least possible to use the JDK for proper conversion, 1.4 was the
last to fail. VFS is a lot older, but it looks like there is plenty of cruft
left, that does not really work as expected either.
> Need an easy way to convert from a FileObject to a File
> -------------------------------------------------------
>
> Key: VFS-443
> URL: https://issues.apache.org/jira/browse/VFS-443
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Nicholas Allen
> Assignee: Gary Gregory
> Fix For: 2.1
>
>
> I've seen the reasons why Apache does not want to provide an easy way to
> convert from a FileObject to a java.io.File and those reasons make sense -
> however, I think that some things are being overlooked and there are still
> valid reasons for needing to convert from a FileObject to a File.
> Firstly, I would like to always use Apache VFS for everything I do - even if
> I know it's only on the local file system. The reasons for this are:
> 1. it makes the code more flexible (it might start of being local file system
> and then as specs change it could become a requirement to work over http or
> inside zip files for example).
> 2. The API is nicer to use than the java.io.File and it's easier to write
> cross platform code using it (file separator is always "/" etc).
> So if I work with Apache VFS for local file system use I would like to be
> able to get back to a java.io.File in case I need to interface with same
> other library. I would like a method that converted to a File or null if not
> possible. This would allow me to take an alternate action (eg copy file to
> local temp file if it's not already a local file). There's no need to copy
> the file if it is already local.
> The simplest fix for this is to just make the getLocalFile() method in
> LocalFile public. Once the user knows it's a LocalFile object it makes sense
> to call this method to obtain the java.io.File. So I could write a method
> like this:
> {code:title=FileUtilities.java}
> /**
> * If the supplied {@link FileObject} represents a local file then this
> returns that, otherwise
> * returns null.
> */
> public File getLocalFile(final FileObject fileObject)
> {
> if (fileObject instanceof LocalFile)
> {
> final LocalFile localFile = (LocalFile)fileObject;
> return localFile.getLocalFile();
> }
> return null;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
