Re: return to the begin of InputStream
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...