[
https://jira.jboss.org/browse/JBVFS-162?page=com.atlassian.jira.plugin.sy...
]
David Lloyd closed JBVFS-162.
-----------------------------
Assignee: David Lloyd (was: John Bailey)
Resolution: Rejected
Unfortunately this is difficult or impossible to support universally. Here's what the
docs say about the two underlying methods we use for this:
java.io.File#length() - "[Returns] the length, in bytes, of the file denoted by
this abstract pathname, or 0L if the file does not exist. Some operating systems may
return 0L for pathnames denoting system-dependent entities such as devices or
pipes."
java.util.zip.ZipEntry#getSize() - "[Returns] the uncompressed size of the entry
data, or -1 if not known"
So java.io.File returns 0 for unknown; we cannot differentiate between file not found vs.
directory vs. something else without using multiple operations, which are not atomic and
thus might fail in unexpected ways.
This issue can be revisited once Java 7 is required for AS, as the new filesystem API
should offer considerably more flexibility on this score.
FileSystem.getSize() should support 'unknown' length
----------------------------------------------------
Key: JBVFS-162
URL:
https://jira.jboss.org/browse/JBVFS-162
Project: JBoss VFS
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Aslak Knutsen
Assignee: David Lloyd
When working with a Stream based FileSystem the size of the Stream could be unknown until
streamed. FileSystem.getSize() forces writing the data to local disk to figure out the
size (or stream it to '/dev/null' ).
FileSystem.getSize() supports a return type of '0L' to indicate a
'directory'. In the same fashion, it could match up with e.g.
URLConnection.getContentLength() and support '-1L' to indicate a 'unknown
size'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira