This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
kittle's profile picture

fs.copy randomly fails

Started by kittle, 04 March 2014 - 05:05 AM
kittle #1
Posted 04 March 2014 - 06:05 AM
Im trying to write a program to auto launch turtles. so far it is working ok. except it randomly fails to copy files to the floppy disk. Im debugging this on single player, so there is no server involved.

relevant code:

turtle.forward()
  scr = fs.open("bootstrap","w")
  ... write stuff to the file ...
  scr.close()
  sleep(1)
  if fs.exists("/disk/startup") then
	 print("delete /disk/startup")
	 fs.delete("/disk/startup")
	 --sleep(3)
  end
  fs.copy("bootstrap", "/disk/startup")

This sits inside a loop and it will ALWAYS fail at fs.copy() but never in the same iteration. when it fails, the message is always the same:
matrun:83 <path to my mc world>\saves\new world\computer\ <some number> \.\disk\startup Cannot find the file specified


Entire program here: http://pastebin.com/xVZJU8NJ

Ideas and suggestions on how to fix this?
or is there a better way to accomplish the same thing?
CometWolf #2
Posted 04 March 2014 - 07:40 AM
Sounds like either the disk is missing, or there's a bug with your mc files. Give it a try on a server or another irl computer.
Bomb Bloke #3
Posted 04 March 2014 - 09:47 AM
Odd that the error includes the full path.

What's "<some number>"? The turtle ID, the disk ID, something else…? Can you see a folder called "disk" at that location?

Does uncommenting that "sleep(3)" make any difference, even if only in rate of occurrence?
kittle #4
Posted 05 March 2014 - 04:13 AM
The <some number> is the turtle ID.
and there is no folder called 'disk' at that location
the disk drive block is sitting on the right of the turtle when the error happens

uncommenting the "sleep(3)" has no visible effect on the error.

Whenever the error happens, I can ALWAYS run "dir disk" and see the disk and my startup file.

At first I wanted to do fs.open("disk/startup", "w") while the turtle was nexto the disk. But that failed immediately
CometWolf #5
Posted 05 March 2014 - 05:34 AM
That is indeed pretty weird. Is it a wireless turtle by any chance?
kittle #6
Posted 06 March 2014 - 02:33 AM
nope. no modems anywhere. just a regular mining turtle.

Is there another / better way to programaticly write a startup file to disk?
or, is there a way to trap the error and try again?
Bomb Bloke #7
Posted 06 March 2014 - 04:07 AM
It sorta reminds me of a thing where I'd move a turtle in front of a barrel, wrap that barrel as a peripheral, go to use one of its functions and… get an error telling me the "computer" wasn't next to the peripheral. Which I'd just successfully wrapped. Fixed that by making my turtle sleep a moment after moving next to the barrel, which is what you're already doing here…

In your case, the error states that ComputerCraft is trying to copy the file into a sub-directory of the turtle's own file system, as opposed to the disk (which is a "separate" file system). That right there is a bug in ComputerCraft, so I'd recommend reporting it as such (assuming you can replicate it in a current version, eg CC1.58 or one of the 1.6 betas).

For what it's worth, my afore-mentioned turtle also auto-launched new turtles as part of its chores (my woodchopping turtles kept on getting eaten by the trees they grew, and so if they didn't report in every so often, this other turtle would assume them to be destroyed and craft new ones). Both it and the new turtles had no issue working with my disk drive. That was under DW20 1.0.11, using CC1.57.

(Well, no issues such as you're describing, at least. After implementing this system, the MineCraft server's average uptime dropped from "weeks" to "about three hours", so it wasn't all roses…)

Anyway, you may be able to get around this with a protected call:

pcall(fs.copy, "bootstrap", "/disk/startup")

The idea is that the script should carry on whether the fs.copy command errors out or not (though you'll still need to implement your own code to see if it worked and retry if not). Since the bug appears to be within CC this may not be effective, however it'd still be worth knowing the results.