commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Davis (JIRA)" <j...@apache.org>
Subject [jira] Commented: (VFS-312) Add FileObjectResolver to provide custom FileObject resolution (FileSystem.resolveFile(...))
Date Mon, 12 Jul 2010 21:08:49 GMT

    [ https://issues.apache.org/jira/browse/VFS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887529#action_12887529
] 

Brad Davis commented on VFS-312:
--------------------------------

Are you suggesting that this would be some sort of mechanism that would intercept my call
to resolveObject() and translate my invalid file name to a valid one?  I don't see a justification
for putting this inside the library as opposed to client code which is using the library.

> 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.


Mime
View raw message