[
https://issues.apache.org/jira/browse/VFS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Siebert updated VFS-312:
------------------------------
Description:
Hello,
I ran into a problem while copying a file with a colon (":") in the file name
from a Unix SFTP FileSystem to a window LocalFileSystem. Windows does not
permit the colon as part of the file name, and it causes the output stream to
fail. Is there currently a way to fix this?
What I would like to propose is to add a
org.apache.commons.vfs.FileObjectResolver interface, which would provide
methods to resolve an input to a (FileSystem) FileObject instance. Then, add
the setFileObjectResolver() and removeFileObjectResolver() methods to the
FileSystem interface to accept this optional resolver. When attempting to
resolve the FileObject, the FileSystem would check to see if an optional
FileObjectResolver was set, and if so, use that. A custom FileObjectResolver
would obviously add additional functionality than simply file name conversions,
but that's the use case we can start with =).
I built a similar model that actually extends the FileSystemManager (instead of
FileSystem) and adds the FileObjectResolver to this class for simplicity (I
REALLY don't want to have to make an extension for each provider =) and it's
working great (except, of course, I have to use the FSM to resolve correctly
rather than directly the FS - a bug I'm hoping to fix by adding this to the
core.
I've downloaded the core from the community SVN and have built a patch I can
contribute, if there is interest. I would be quite happy to contribute the
patch.
Thanks for taking a look!
Steve
was:
Hello,
I ran into a problem while copying a file with a colon (:) in the file name
from a Unix SFTP FileSystem to a window LocalFileSystem. Windows does not
permit the colon as part of the file name, and it causes the output stream to
fail. Is there currently a way to fix this?
What I would like to propose is to add a
org.apache.commons.vfs.FileObjectResolver interface, which would provide
methods to resolve an input to a (FileSystem) FileObject instance. Then, add
the setFileObjectResolver() and removeFileObjectResolver() methods to the
FileSystem interface to accept this optional resolver. When attempting to
resolve the FileObject, the FileSystem would check to see if an optional
FileObjectResolver was set, and if so, use that. A custom FileObjectResolver
would obviously add additional functionality than simply file name conversions,
but that's the use case we can start with =).
I built a similar model that actually extends the FileSystemManager (instead of
FileSystem) and adds the FileObjectResolver to this class for simplicity (I
REALLY don't want to have to make an extension for each provider =) and it's
working great (except, of course, I have to use the FSM to resolve correctly
rather than directly the FS - a bug I'm hoping to fix by adding this to the
core.
I've downloaded the core from the community SVN and have built a patch I can
contribute, if there is interest. I would be quite happy to contribute the
patch.
Thanks for taking a look!
Steve
added quotes around the colon symbol to prevent the emoticon generation
> Add FileObjectResolver to provide custom FileObject resolution
> (FileSystem.resolveFile(...))
> --------------------------------------------------------------------------------------------
>
> Key: VFS-312
> URL: https://issues.apache.org/jira/browse/VFS-312
> Project: Commons VFS
> Issue Type: New Feature
> Environment: To help support cross-platform file name resolution
> Reporter: Steve Siebert
> Priority: Minor
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Hello,
> I ran into a problem while copying a file with a colon (":") in the file name
> from a Unix SFTP FileSystem to a window LocalFileSystem. Windows does not
> permit the colon as part of the file name, and it causes the output stream to
> fail. Is there currently a way to fix this?
> What I would like to propose is to add a
> org.apache.commons.vfs.FileObjectResolver interface, which would provide
> methods to resolve an input to a (FileSystem) FileObject instance. Then, add
> the setFileObjectResolver() and removeFileObjectResolver() methods to the
> FileSystem interface to accept this optional resolver. When attempting to
> resolve the FileObject, the FileSystem would check to see if an optional
> FileObjectResolver was set, and if so, use that. A custom FileObjectResolver
> would obviously add additional functionality than simply file name
> conversions, but that's the use case we can start with =).
> I built a similar model that actually extends the FileSystemManager (instead
> of FileSystem) and adds the FileObjectResolver to this class for simplicity
> (I REALLY don't want to have to make an extension for each provider =) and
> it's working great (except, of course, I have to use the FSM to resolve
> correctly rather than directly the FS - a bug I'm hoping to fix by adding
> this to the core.
> I've downloaded the core from the community SVN and have built a patch I can
> contribute, if there is interest. I would be quite happy to contribute the
> patch.
> Thanks for taking a look!
> Steve
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
