[1.47]File handle bug always returning "Access denied"

There is a bug that when you use the lua interpreter and don't close a file handle before exiting it, the file is undeletable until you restart Minecraft. This also works when a program is terminated with a file handle still open. If you now try to delete it from in-game, it'll just return "Access denied", also, the Windows Explorer (yes, running Windows) can't close it, as it's still opened in Java. You can't close the file with the lua interpreter anymore, as the handle is destroyed. Just closing the MC world also won't help, Minecraft needs to be restarted. I don't think this is a Windows only problem, since the file isn't closed automatically on exiting the interpreter/terminating the program.

When the computer is restarted it should unmount all the file handles. What version of CC are you using?

ive seen something similar to this
my turtle swarm gen would stop working because turtles would randomly error "access denied" (before printing turteOS)
thats why i made the swarm controller automatically reboot the computer if it dosent move

Cloudy, on 21 December 2012 - 09:39 AM said:

When the computer is restarted it should unmount all the file handles. What version of CC are you using?

I'm using 1.47. When I restart the computer, everything seems to work fine, but I think it would be better if all file handles would be closed when terminating a program/exiting the interpreter.

That isn't really possible without logic in the interpreter/shell to do that - just make sure you close handles yourself properly :P/>

Cloudy, on 22 December 2012 - 04:52 AM said:

That isn't really possible without logic in the interpreter/shell to do that - just make sure you close handles yourself properly :P/>

I normally do, but when a program crashes before all the handles get closed, the same thing will happen.

Cakejoke, on 22 December 2012 - 07:37 AM said:

Cloudy, on 22 December 2012 - 04:52 AM said:

That isn't really possible without logic in the interpreter/shell to do that - just make sure you close handles yourself properly :P/>

I normally do, but when a program crashes before all the handles get closed, the same thing will happen.

Then do incremental writes to allow for this. If a program crashing and leaving the handle open then don't leave a file open for a long time, process all the data you want to put into it, then open -> dump -> close. and with reading from the file, open -> read all -> close then process the data, instead of reading line by line. Both of these operations would work so quick that if the program crashes exactly when it does it, your damn unlucky!

Cakejoke, on 21 December 2012 - 09:38 AM said:

I don't think this is a Windows only problem, since the file isn't closed automatically on exiting the interpreter/terminating the program.

A Unix based computer (Linux or Mac) doesn't have problems with file handlers staying open. You can open, move, or delete them at will, the OS will update the handlers reference to the file. I do it all the time, watching a video and want to copy it somewhere else and rename it, yeah that can be done, with no negative effects to playback, the handler just gets told the new name and location of the file ;)/>

Cakejoke, on 22 December 2012 - 03:54 AM said:

Cloudy, on 21 December 2012 - 09:39 AM said:

When the computer is restarted it should unmount all the file handles. What version of CC are you using?

I'm using 1.47. When I restart the computer, everything seems to work fine, but I think it would be better if all file handles would be closed when terminating a program/exiting the interpreter.

As long as it can be fixed simply by restarting Computer it is not a big problem. But can file closing be tied with garbage collecting of file handlers? Not to program closing.

TheOriginalBIT, on 22 December 2012 - 01:27 PM said:

Cakejoke, on 22 December 2012 - 07:37 AM said:

Cloudy, on 22 December 2012 - 04:52 AM said:

That isn't really possible without logic in the interpreter/shell to do that - just make sure you close handles yourself properly :P/>

I normally do, but when a program crashes before all the handles get closed, the same thing will happen.

Then do incremental writes to allow for this. If a program crashing and leaving the handle open then don't leave a file open for a long time, process all the data you want to put into it, then open -> dump -> close. and with reading from the file, open -> read all -> close then process the data, instead of reading line by line. Both of these operations would work so quick that if the program crashes exactly when it does it, your damn unlucky!

Cakejoke, on 21 December 2012 - 09:38 AM said:

I don't think this is a Windows only problem, since the file isn't closed automatically on exiting the interpreter/terminating the program.

A Unix based computer (Linux or Mac) doesn't have problems with file handlers staying open. You can open, move, or delete them at will, the OS will update the handlers reference to the file. I do it all the time, watching a video and want to copy it somewhere else and rename it, yeah that can be done, with no negative effects to playback, the handler just gets told the new name and location of the file ;)/>

Then I guess I am damn unlucky. :P/>

Ah, thanks for clearing me up on that Windows/Unix stuff. I'm planning on trying out Linux soon anyway, then I'll see myself…