Andrea,
This makes sense if the base file systems is/are a real file system. The
Native File System being such a case.
However it does not make sense if using a JDBC, Persistence, Virtual
File System, or even an FTP Proxy. In these cases, the files are really
Objects, not "tangible" files located on a disk drive. It's really more
than just a name change or semantic, it's the intent, what it
[FileObject], really represents.
I suspect there are two issues here that are confusing?
1) File Metadata
2) File Content
These are not always in the same location, more often than not, they are
not together in a virtual or distributed system. In these, the metadata
is typically in a database, and the content is on some remote storage
system, NetApps Filer, EMC Centera, Sun Thumper, SAN, Windows Server, or
even another FTP Server [local disks].
The FileObject accurately represents what the FTP server is actually
handling, file metadata and file content, where the two may not be
physically located together. In other words, the FileObject is purposely
abstract about each, providing flexibility to handle different approaches.
When I first started working with the code, I too thought the same thing
when I first saw this. Huh?, FileObject? Hey, I'll make it a File not
FileObject, then I realized what was going on, and said to myself, hey
whoever did this was thinking ahead.
This is a little off topic, but it is related. Think about it this way,
a FileObject typically has only one copy of metadata, but it can have
many copies of the file content located on different storage devices.
Simply changing the stream from a local disk to a url-stream allows
access to those copies. Why is this important? For some it's about
having multiple back-up copies in the case if a disaster, for others it
might be near and distant data center and costs access to them.
See the intent behind the FileObject? It's flexible, not only in code,
but also in thought.
In my opinion, I would leave the FileObject as-is, if it's really
causing issues, make changes in a local copy. I suspect though, that as
the world moves to more object-based storage, the local changes will be
a major problem. It's not just a simple name change, it's what it
represents :-).
... my two-cents worth
Andy Thomson
Andrea Francia (JIRA) wrote:
After the renaming FileObject->FtpFile the method FileSystemView#getFileObject
should renamed
---------------------------------------------------------------------------------------------
Key: FTPSERVER-189
URL: https://issues.apache.org/jira/browse/FTPSERVER-189
Project: FtpServer
Issue Type: Bug
Reporter: Andrea Francia
I propose to rename from:
FtpFile getFileObject(String file) throws FtpException;
to:
FtpFile getFile(String path) throws FtpException;
There is a patch for this.
