commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B. K. Oxley (binkley)" <bink...@alumni.rice.edu>
Subject Re: [vfs] proposal: MemoryFS
Date Sat, 29 Jan 2005 19:55:58 GMT
Mario Ivankovits wrote:
> Your solution is just as good. But you have to ensure you really handle 
> it like the "host" within the other filesystems. The point is VFS has to 
> create a new filesystem instance for every "set", else all "sets" are 
> tied together in one filesystem and maybe never get garbage-collected as 
> someone might use a RamFS in an long time work.

Ah, I see.  I just abstracted out the file-y bits into a RamFile class:

public class RamFile {
     private final Map<String, Object> attributes = new HashMap<String, 
Object>();

     // TODO: what can be marked final?
     private FileType type = FileType.IMAGINARY;
     private byte[] buffer;
     private Set<String> children;
     private boolean hidden;
     private boolean readable;
     private boolean writeable;
     private long lastModifiedTime;

     // And appropriate getters/setters.
}

I could abstract futher, if need be, and turn the getters/setters into 
an interface.  The simple implementation would be like the one above. 
More interesting ones might wrap java.io.File or work with a C-API via 
JNI (for the fellow interested in native code).

The "set" idea is right now just expressed in FileName.  I haven't coded 
a filesystem tree to represent the directory-subdirectory-file 
relationships yet.

Where do I send code?


Cheers,
--binkley

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message