Mario Ivankovits wrote:
Current:
file = getManager().resolveFile(%2e);
resolves to the current Directory
New:
resolves to a file or directory NAMED .
I don't think there is a filesystem where this is possible. I'd need to
read the relevant W3C specs to be sure.
resolves to a file or
I'm unsure that the URI specs intend to distinguish a string from it's
encoded form for the purposes of naming. I believe they are to be
interpreted equivalently, and that the encoding exists only to permit
uncorrupted transmission of forbidden characters.
You have found something interesting
Rami Ojares wrote:
file.toURI().toString() is not the way to go.
The reason is simple. It does not work.
What does it does not work mean? That is, what is an example failure
case?
Cheers,
--binkley
-
To unsubscribe, e-mail:
Rami Ojares wrote:
new File(new URI(
(new File($%[EMAIL PROTECTED]|\\^[]`$)).toURI().toString()
)).getPath()
Returns $%[EMAIL PROTECTED]|\\^[]`$
Which is correct.
Yikes!
I want to hire you to do all my software testing. That is diabolical.
Cheers,
--binkley
Rami Ojares wrote:
public FileObject findLocalFile(final File file)
throws FileSystemException
{
// TODO - tidy this up, should build file object straight from the file
return findFile(null, file: +
ENCODE_URI_SOMEHOW(file.getAbsolutePath()), null);
}
I would do even less work than
[EMAIL PROTECTED] wrote:
I just saw a memory proposal from B. K. Oxley on the dev list. I was silly no to
check it before. Sorry.
But I have been slow in working on it.
Cheers,
--binkley
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Why are some of the write methods in NullOutputStream synchronized?
Example:
public synchronized void write(byte[] b, int off, int len) {
//to /dev/null
}
Cheers,
--binkley
-
To unsubscribe, e-mail: [EMAIL
Stephen Colebourne wrote:
Cut and paste?!!
You prefer a patch removing the synchronized keywords? :-)
Again, is there some technical reason for empty-bodied methods to be
sychronized?
Cheers,
--binkley
-
To unsubscribe, e-mail:
I've scored copies of IntelliJ IDEA for developing VFS from JetBrains:
http://www.jetbrains.com/idea/opensource/
What should be the official project name for the purposed of licenses?
Is just Jakarta Commons VFS good enough? How many licenses are needed?
Cheers,
--binkley
Henri Yandell wrote:
Meant to send them an email yesterday to ask how they wanted to handle licences.
ie) could we just organise an ASF licence, would it be per person etc.
I am not a committer for ASF. Would this still apply to me?
Cheers,
--binkley
Henri Yandell wrote:
Probably not.
Seems like a bit of an anomaly.
I imagined it would be rare for somebody to pass Jetbrains' rule of:
Some evidence of your engagement in the project and want to use an
IDE for that project and not be either a committer, or making a lot of
contributions/patches
Stephen Colebourne wrote:
public static void copyAndClose(final InputStream in,
final OutputStream out)
throws IOException {
try {
CopyUtils.copy(in, out);
out.flush();
} finally {
IOUtils.copyAndClose(in);
IOUtils.copyAndClose(out);
This is the sort of tree I was asking about (below) to represent the
memory file system. I want to avoid reusing DefaultTreeModel for a data
structure since it is Swing-oriented (look at all the listeners!).
I'd expect to specialize the generic thus:
public class RamTree extends TreeString,
I note in my blog:
http://binkley.blogspot.com/2005/02/methods-i-cannot-do-without.html
It would be nice to include utility methods such as this in the io
library to compliment the good set of primitives already there.
The method in question with Javadoc added:
/**
* Copies varin/var to
Mario Ivankovits wrote:
In pseudo code:
UndoStack tx = new UndoStack();
try
{
Backup(tx, ...)
Copy(tx, ...)
Move(tx, ...)
}
catch (Exception)
{
tx.rollback(); - process undo-stack
}
This looks ok. I still prefer each command to handle it's own cleanup
(try/catch/finally in part existing for
Mario Ivankovits wrote:
JDK5: Dont forget, our target is jdk1.3 (even if I use 1.5 since it is
out) You cant imagine how fast the first user shouted after I used (by
mistake) a jdk 1.4 method.
JDK 1.3!? I had no earthly idea.
-
What's the right way to make a temporary file with VFS? I need some for
unit tests. For the nonce I did this:
FileObject createTemporary() {
// Using JDK UUID generator -- is this JDK1.3-compiant?
final FileObject tmp = VFS.getManager().resolveFile(
tmp:/ +
Mario Ivankovits wrote:
But this has several drawbacks, among them:
* No automatic cleanup on exit as with File.deleteOnExit()
Yes - and in my opinion thats ok so. If you run VFS in an WebApp
environment the next exit might be very long in the future. And even
then, if the jvm crashes or is
Continuing the command pattern, I rejiggered the Save command to use a
Backup command rather than hard-coding the backup policy:
public class Save implements IOOperation {
private final Backup backup;
private final InputStream newContents;
private final FuFile original;
public
Mario Ivankovits wrote:
Where do you think to implement this FileOperation interface? I miss
the source fileobject -a s I said, I dont want to implement the
interface in the FileObject and thus thought about something like
this:
DefaultFileOperations.get().copy(FileObject src, FileObject
I looked over the problem again and think I'd prefer a command object
approach:
public interface OperationE extends Exception {
void execute() throws E;
}
And:
public interface IOOperation extends OperationIOException { }
(Excess abstraction, I know. I had a hard time resisting the coolness
What is the rational behind forbidding that imaginary files be renamed?
My RamFS uses a tree to represent the in-memory filesystem and the
naming of nodes in the tree is separate from the nodes themselves, so a
rename operation is independent of the file type.
Cheers,
--binkley
Mario Ivankovits wrote:
I tried this with an ordinary local-file. And beside the fact, that the
local file cant be renamed as it isnt existent, VFS successfully passes
the request down to the LocalFile implementation.
I based my question on the Javadocs for doRename() which tell me that it
will
How is this for an interface for file operations?
public interface FileOperation {
void save(final InputStream newContents)
throws FileSystemException;
void saveAndBackup(final InputStream newContents)
throws FileSystemException;
void copyTo(final FileName
Mario Ivankovits wrote:
One thing I currently thougth about is the scope of its content. By
default the content is global to all users using the singleton
FileSytemManager.
Though, we could use the FileSystemOptions to force VFS to create a new
RamFileSystem instance.
I'm not certain how the
Mario Ivankovits wrote:
Just one additional idea:
Please design the internal data-store in a whay that it is serializable.
I'm using fields in the RamFileObject itself for all the various
properties, contents, etc. (at least until I introduce RamFileContent --
right now I just have RamFileName,
Mario Ivankovits wrote:
If there is a user who uses JAVA, VFS and its RamFS and states the RamFS
is too slow for its usage, we could talk about it.
Until this appens, I dont want to see native code within VFS.
Provide native code for all possible architectures is way too much work
- at least
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
B. K. Oxley (binkley) wrote:
I'm thinking of implementing a memory filesystem with VFS as a
demonstration. The demo filesystems for local files and URLs are fine
and good, but they are not very pedagogic for implementing virtual
features. For example, they do not do much with attributes
I'm thinking of implementing a memory filesystem with VFS as a
demonstration. The demo filesystems for local files and URLs are fine
and good, but they are not very pedagogic for implementing virtual
features. For example, they do not do much with attributes. A
filesystem implementation
For inclusion in the VFS I propose a higher-level API which wraps the
lower-level FileObject operations for ease of use in applications.
In particular, I would like to capture these principles:
* Do-or-die semantics.
* Transactional semantics.
* Completed operations.
* Instance methods.
* Easy
Mario Ivankovits wrote:
About transactionality :- care should be taken to not reimplement
something like [transaction], they already implemented such a beast
using java.io.File. Maybe we can adopt it.
I'll have to look at it, but it looked like overkill for what I had in mind.
I've been toying
Stéphane Rault wrote:
I'm trying to use the wonderful VFS. It works quite well but I've a
problem with writing in zip file. Searching for informations, I wonder
if VFS is still a live project and if sometimes, it will leave the
sandbox to become a complete Jakarta-Common project ?
I'd like to
http://jakarta.apache.org/commons/sandbox/vfs/download.html
The link for Commons Collections points to the logging library instead.
Cheers,
--binkley
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
34 matches
Mail list logo
