return to the begin of InputStream
in [Java Help]
|
From: Tom Anderson on 11 Dec 2009 17:31 On Fri, 11 Dec 2009, Martin Gregorie wrote: > On Thu, 10 Dec 2009 18:13:48 +0000, Tom Anderson wrote: > >> Now, i have been assuming that writing to a mapped file which *does* >> live on disk affects the timestamp. Here is a test: In other words, >> writing to a mmapped file doesn't change the mtime. Yikes! > > Something about this niggled me - the effect of using coarse > (millisecond) time resolution and a fast (1.6 GHz) CPU when checking the > effect of single statements, so I rewrote your program to add 1000 mS > pauses between interesting groups of statements. My reasoning was that were were interested in at what stage the timestamp changed, but not what it changed to. You're right that if one of the operations had a delayed effect, in my implementation, it would show up under the timestamp for another operation, and checking for that is prudent. > This shows that, on a Linux system anyway, the modification timestamp is > updated when a RandomAccessFile is written or a MappedByteBuffer is > changed. So it does. What OS are you on? Results from a java claiming to be Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-306) Java HotSpot(TM) Client VM (build 1.5.0_19-138, mixed mode, sharing) on a machine calling itself Darwin localhost 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc: 1 Create,open raf : = 1260569419000 2 Write : = 1260569420000 3 Sync : = 1260569420000 4 Mapped,put : = 1260569420000 5 Force : = 1260569420000 6 Close : = 1260569420000 7 Reopen raf : = 1260569420000 File content : = Mapd file 8 Read : = 1260569420000 9 Close : = 1260569420000 So no change from writing to the file via an mmap. From java version "1.5.0" gij (GNU libgcj) version 4.3.2 on what purports to be Linux urchin 2.6.26-2+urchin.1-686-bigmem #1 SMP Tue Nov 24 16:50:32 GMT 2009 i686 GNU/Linux: 1 Create,open raf : = 1260569830000 2 Write : = 1260569831000 3 Sync : = 1260569831000 4 Mapped,put : = 1260569833000 5 Force : = 1260569833000 6 Close : = 1260569833000 7 Reopen raf : = 1260569833000 File content : = Mapd file 8 Read : = 1260569833000 9 Close : = 1260569833000 Change! Obamatastic! From java java version "1.5.0_14" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) J on Linux localhost 2.6.18-92.1.10.el5 #1 SMP Tue Aug 5 07:41:53 EDT 2008 i686 athlon i386 GNU/Linux: 1 Create,open raf : = 1260570108000 2 Write : = 1260570109000 3 Sync : = 1260570109000 4 Mapped,put : = 1260570109000 5 Force : = 1260570109000 6 Close : = 1260570109000 7 Reopen raf : = 1260570109000 File content : = Mapd file 8 Read : = 1260570109000 9 Close : = 1260570109000 No change. So now i'm completely baffled. > No other operations on an existing file including flushing its > buffers (FileDescriptor.sync() and MappedByteBuffer.force()) affect the > amended timestamp. > > Here are the labelled timestamps: > > $ java MMapTest > 1 Create,open raf : = 1260562842000 > 2 Write : = 1260562843000 > 3 Sync : = 1260562843000 > 4 Mapped,put : = 1260562845000 > 5 Force : = 1260562845000 > 6 Close : = 1260562845000 > 7 Reopen raf : = 1260562845000 > File content : = Mapd file > 8 Read : = 1260562845000 > 9 Close : = 1260562845000 tom -- The exact mechanics are unknown, but a recent sound file revealed the process to go something like this: WONKA WONKA WONKA WONKA DEOO DEOO DEOO DEOO WOWOWOWOWOWOWOWOWOWOWOW WONKA WONKA WONKA...
From: Martin Gregorie on 11 Dec 2009 19:49 On Fri, 11 Dec 2009 22:31:06 +0000, Tom Anderson wrote: > My reasoning was that were were interested in at what stage the > timestamp changed, but not what it changed to. You're right that if one > of the operations had a delayed effect, in my implementation, it would > show up under the timestamp for another operation, and checking for that > is prudent. > Yes, that's clear. After posting, I modified my code so I could vary the wait time and found that the timestamp change lost its correlation with the program action if I set the wait to less than 450 mS. At first I thought this showed that timestamp changes were not synchronised with the write actions but then I realised that the timestamp is only 1 second accuracy, so probably the timestamp only detectably updates with the first write after the least significant second digit has changed. The lack of correlation with flush operations isn't surprising for a *nix: the inode would be updated in memory and would show immediately in mtime queries. Some time later, the affected blocks would be flushed to disk but this is merely an internal filing system housekeeping operation, unlike updating mtime in the inode, so you wouldn't expect the fs sync to affect the mtime value. > So it does. What OS are you on? > Fedora 10, kernel version 2.6.27.38-170.2.113.fc10.i686 java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing) Running on an Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz > Results from a java claiming to be Java(TM) 2 Runtime Environment, > Standard Edition (build 1.5.0_19-b02-306) Java HotSpot(TM) Client VM > (build 1.5.0_19-138, mixed mode, sharing) on a machine calling itself > Darwin localhost 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc: > > 1 Create,open raf : = 1260569419000 > 2 Write : = 1260569420000 > 3 Sync : = 1260569420000 > 4 Mapped,put : = 1260569420000 > 5 Force : = 1260569420000 > 6 Close : = 1260569420000 > 7 Reopen raf : = 1260569420000 > File content : = Mapd file > 8 Read : = 1260569420000 > 9 Close : = 1260569420000 > > So no change from writing to the file via an mmap. > I know very little about PPC Macs so can't comment about this. However, I'm a little surprised that your second Linux run does the same: its still kernel 2.6 so, barring bugs, I wouldn't expect a difference. Similarly, I'd be quite surprised if the JVM has any effect on this because mtime updating is, or should be, an OS function. It may be worth increasing the wait time to 1500 - 2000 mS and running your three tests again to see if that changes anything. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Arne Vajhøj on 3 Jan 2010 20:22 On 03-12-2009 18:54, markspace wrote: > Arne Vajh�j wrote: >> Anabolik wrote: >>> How to return to the begin of InputStream after reading this file? >> >> Close and reopen the file. > > Good idea. Another in the same vein, if the stream is a network stream > that can't be re-opened (easily), then make a temp file and copy it to > the temp file. Then you can re-open the temp file as random access. If it is a disk file, then I would expect it to be one of the safest ways of doing it. Arne
First
|
Prev
|
Pages: 1 2 3 4 5 6 Prev: Forcing garbage collection Next: Problem tracking down an error |