[
https://issues.apache.org/jira/browse/VFS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496995#comment-13496995
]
Nicholas Allen commented on VFS-443:
------------------------------------
Looking at the LocalFile.java class it looks like the implementation has bugs
in it. Just making getLocalFile() public will not work because this just
directly returns the field and in my debugger I can see that this is null at
this point. It seems the file has to be attached first. Looking at the
LocalFile.doAttach() method it seems that this just uses the decoded path in
the name but on Windows this should be with "\" not "/" and also the C:\ part
is missing. I can't debug it yet to check but that is what I would expect to
happen.
{code:title=LocalFile.java}
/**
* Returns the local file that this file object represents.
*/
protected File getLocalFile()
{
return file;
}
/**
* Attaches this file object to its file resource.
*/
@Override
protected void doAttach() throws Exception
{
if (file == null)
{
// Remove the "file:///"
// LocalFileName localFileName = (LocalFileName) getName();
String fileName = rootFile + getName().getPathDecoded();
// fileName = UriParser.decode(fileName);
file = new File(fileName);
}
}
{code}
> 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:
> /**
> * 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;
> }
--
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
