Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

What's wrong with renameTo()?  RSS feed

 
Verena Dear
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I'm trying to use the renameTo()-function of the file-object. It seems as if it does not what I want it to do. It depends on somewhat (weather, airpressure or something?!) wether it renames the file or not. Additionally it seems to be unusable because of the digital errorcode - yes / no.

Is there any hidden secret to this function, that I must know. Or is there any alternative to the file-class that works platform independent?

I am working on Linux - for Windows it is completely unusable. I am pretty sure that the file is not occupied by something else, because one time it is renamed and the other not. Or must there be a cleanup for the file? I already closed the filechannel and randomaccessfile that I opened previously on the same file.

I am pretty clueless now.

Thanks for help,

--Verena
 
Jeramie Maratas
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try to close all input and outputstreams before renaming the file.. Let me know the results.
 
Verena Dear
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I never opened an input- or outputstream on this file. Only a mappedByte Buffer, but everything else is closed and set to null. And remember, that it works one time and the other not - for the same scenario.

--Verena
 
clio katz
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
can you post the code?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Only a mappedByte Buffer, but everything else is closed and set to null.

The MappedByteBuffer is more than sufficient to cause the troubles you describe. Reading the API for this class (and FileChannel's map() method which presumably created it) we see that the mapping between a MappedByteBuffer and its associated is valid until the MBB itself is garbage collected. And there is no way to guarantee that it will ever be collected - until the JVM actually exits, that is. What's not documented here is the effect this mappiong has on the renameTo() method - my guess it, it will prevent renameTo() from succeeding until the MBB is collected. You can't do anything to change this - not reliably, anyway. I would say that if you want to be able to rename the file later, you can't use a MappedByteBuffer. Or vice versa.
 
Verena Dear
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you,

so it is once again the MappedByteBuffer that makes the function behave that strange. Unfortunately I have no chance to change that, because I need to create the MappedByteBuffer to pass it to lower functions.

I will have to discuss that with my collegues.

--Verena
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!