poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Murphy, Mark" <murphym...@metalexmfg.com>
Subject RE: NPOIFS, files and the read-only flag
Date Fri, 10 Feb 2017 19:48:54 GMT
I guess I don't understand this that well, so please bear with me. With a File loaded read-write
how are changes stored such that writing to a different OutputStream is not feasible? I don't
think they are written back to the original File until a write operation is performed. Or
is that incorrect?

-----Original Message-----
From: Nick Burch [mailto:nick@apache.org] 
Sent: Friday, February 10, 2017 1:42 PM
To: POI Developers List <dev@poi.apache.org>
Subject: NPOIFS, files and the read-only flag

Hi All

Currently, in NPOIFS (NPOIFSFileSystem + POIFSFileSystem, but not OPOIFSFileSystem), you can
either load from a File or from a Stream. 
With a Stream, everything gets buffered into memory

When loading from a File, you can load read-write or read-only. In read-write mode, we use
NIO to mmap the file so we can quickly + low memory read + write.

The other case, File + read-only, isn't so ideal. We need to support both people doing true
read-only cases, eg reading or text extraction, plus people doing read-template + write or
read-change-saveas cases. To support that, we buffer into memory.

Taking another look at the NIO stuff for bug #60670, I was wondering about splitting those
two cases out. For true read-only cases, we could then mmap in read-only mode. For cases where
you're loading a file and want to change + save elsewhere with the original unchanged, I think
we could mmap in "private" mode, which looks to be copy-on-write, so only changes would be
buffered in memory.

Any thoughts? Is it worth making the change? Can anyone spot any downsides to the change?
Anyone think of any good enum names for the different modes if we replace the read-only boolean
with a 3-way enum?

(Changing all file-based access to mmap, rather than a mix of mmap + in-memory buffers, should
make it easier to tweak the logic to mmap bigger chunks)

Cheers
Nick

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


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

Mime
View raw message