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

[SOLVED][Lua][Help]My OS seems to interfere with a script called Gitget

Started by Geforce Fan, 08 June 2015 - 08:43 PM
Geforce Fan #1
Posted 08 June 2015 - 10:43 PM
I'm not really sure why this happens. My OS overwrites:
  • Shell.run
  • os.run
  • fs.open + any other FS functions dealing with files
  • fs.isReadOnly
  • os.loadAPI
It does this in order to introduce a file protection system(Which has several loopholes at the minute, which is why the OS is in alpha). This allows users to give files different permissions for different users.
However, for some reason this seems to interefere with the script Gitget–it is unable to fetch certain files. The trouble is not with writing them, but that they come up blank when fetched from Github–or at least, from what I can see.
Steps to reproduce, from a new advanced computer:

pastebin run 6JU1nY50 update 5
Now, make an account
Type 'sudo rm .meta'(this will make all files unlocked)
type 'pastebin run W5ZkVYSi AI221 potato'(or any other thing on github)

This really makes no sense whatsoever, as I haven't changed anything with networking.
I have a time daemon that fetches the time each time it rolls over from :59 seconds, but I've tried disabling that and still the problem persists.
If I try to download things without the OS, everything works perfectly. I've even tried running gitget in sudo, but it still does not work.
Edited on 10 June 2015 - 04:31 AM
Bomb Bloke #2
Posted 09 June 2015 - 01:22 PM
W5ZkVYSi:54: attempt to index ? (a nil value)

Line 54 of W5ZkVYSi:

local file = shell.resolve(file:gsub("%%20"," "))

Basic use of print statements confirms file is nil, because paths[a] at line 124 is nil.

"a" is a string representing a link, "https://api.github.com/repos/AI221/potato/git/trees/master?recursive=1", a match for the URL contacted at line 74. It isn't mentioned again, implying that the event "a" is defined by shouldn't have any reference to it, and hence that there's a broken coroutine manager somewhere.

Searches in your main OS code, library\executable, for references to coroutine.resume() and os.pullEvent(), leads to omni.initRoutines(). Sure enough, you aren't properly respecting what's in your "requests" table, and your code may resume coroutines with events they didn't ask for.

I'm not sure what the deal with your "protected" coroutines is - you don't even record what events they want, let alone check them before passing them in. I sort of get the impression that's intentional.

Certainly, however, you should be performing a check against requests before the resume call on line 286.
Geforce Fan #3
Posted 10 June 2015 - 12:01 AM
Thanks! I didn't even think it might have been the coroutine system. I almost just decided that updating should involve overwriting startup to update and then rebooting!

I initially created the entire routine system to be used specifically by the GUI and never the console, but later decided I wanted daemons.
The "protected" routines where to be the menu bar, and perhaps other things later down the line. I initially was going to have some sort of isolation, but later decided I wouldn't be sandboxing anything–programs could generally do equal damage to other (well-written) programs with os.shutdown()

I'll probably rewrite the entire coroutine resumer–it's messy and unintuitive at best