• Post Reply Bookmark Topic Watch Topic
  • New Topic

FileOutputStream flush position of channel  RSS feed

 
n romaai
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Im writing to a BufferedOutputStream( FileOutputStream ) and I want to occasionly record the position that the file stream is at.



the bytes may not be written to file at the time flush is completed (from the documentation for OutputStream.flush)
so, does this mean the position I get from theChannel.position() might not represent all the bytes written so far?

Im also trying to keep the channel instance separately, but I guess I dont have to.
Will only the fileChannel returned from fos.getChannel have the current position?
In other words, if I store fileChannel instance, then write to the underlying fileOutputStream,
will the old fileChannel instance see that change?
calling position on the old instance will give the position correctly with the intervening write call?

Does anybody know how much I can rely on this?
I just wanted to ask and see before I spent a lot of time googling and experimenting
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You have it the wrong way around. FileChannel doesn't have an underlying OutputStream, FileOutputStream has an underlying FileChannel. Anything written or read from either of the two will be reflected by the other.

Flushing the stream may not guarantee that the data is physically written to disk, but subsequent operations on the file system should appear as if the data was fully written. The only reason they can't make this guarantee is because the operating system may cache the data or store it somewhere else before writing it to the actual file. This is completely invisible to your program, and you shouldn't have to worry about it at all. It should only affect you if the system is reset or crashes or otherwise terminated abruptly while your program is running.
 
n romaai
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Stephan van Hulst

Thanks, you answered my question.

I kinda figured that I could rely on the correctness of position() and its consistency across storing the fileChannel instance but got worried when I saw the documentation for OutputStream.flush()
It sounds like any discrepancy is way in the operating system, like, transparent even to the VM...
The documentation is probably just being thorough for implementations of OutputStream

plus now I dont have to try to track number of bytes "written" myself

would I even have to flush the outer bufferedOutputStream to see the correct position() ?
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No. Position is completely independent from flushing. The position is determined through write and read operations only.

I also wouldn't call it a discrepancy in the operating system. The data passed to the operating system is often cached before it's physically written. This is done to speed up all sorts of operations. It's a very well thought out process. The disadvantage is that the VM won't be able to make guarantees about where the data finally ends up.
 
n romaai
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, that does not seem true.



Results:



On CentOS 5
It seems the fileOutputStream does not update position until the outer outputStream is flushed
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you sure? Are you sure it's not the BufferedOutputStream that's preventing the immediate updating of the position?
 
n romaai
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what I said is:

until the outer, buffered outputstream is flushed

only then does the inner, file outputStream

see the bytes coming in

so,

the outer bufferedOutputStream keeps

- or prevents -

the bytes from being written to the inner fileOutputStream

 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's because it's buffering the data; it's keeping it in memory until a) you flush it, or b) its buffer is full. Hence the Buffered part of the name.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yep. you should not mix operations on different levels of stream wrappers, if they use some sort of buffer in between, or alter the data written in some way. Like BufferedInputStream, another example would be InflaterInputStream.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!