I know from my File::Temp porting issues that Windows does not let you
unlink an open file whereas unix essentially uses reference counting so
deleting an open file doesn't remove the file until the file is closed
(the act of opening the file ups the "reference count"). In File::Temp
there is a list of operating systems that don't allow the unlink of open
and the module has to work around things.
I'm assuming explicitly garbage colleting the MappedByteBuffer will cause
the file to be deleted?
So I don't think Windows will allow this regardless of Java's cross
platform portability.
Tim
On Fri, 10 Dec 2004, Mark Taylor wrote:
> Friday quiz.
>
> On Linux, if I map a file (using java.nio.MappedByteBuffer), then delete it,
> then write a new file to the same name, the data in the original file
> remains intact until the file becomes unmapped (e.g. at process death),
> at which point the space is returned to the filesystem. In particular
> it's not overwritten by whatever I write to the new file with the same
> name. This is what I'd expect to happen on any un*x-like system.
>
> Can anyone tell me if the same thing happens on Windows (in general:
> is it a fair assumption that systems which support file mapping will
> behave in this way)?
>
> thanks
>
> Mark
>
> --
> Mark Taylor Starlink Programmer Physics, Bristol University, UK
> [log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
>
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|