3
[1.53] Api function for file modify date or age
Started by Aedda, Apr 03 2013 12:09 PM
13 replies to this topic
#1
Posted 03 April 2013 - 12:09 PM
For purposes of syncing files across computers and turtles I would like to see an api call to return the last modify date of a file. This could be implemented as either returning the day and time as comparable to os.day() and os.time(), or the amount of time since the file was modified in ticks or seconds.
Thank you for your consideration, regardless of your decision.
????
Profit?
Thank you for your consideration, regardless of your decision.
????
Profit?
#2
Posted 03 April 2013 - 12:21 PM
You could do this your own by modifying the edit and some other stuff
#3
Posted 03 April 2013 - 12:35 PM
Modify fs.open to save the time and date to a file, then have a function to read from that file.
#4
Posted 03 April 2013 - 01:43 PM
Thank you for the suggestions. I had considered my own api wrapping the file functions but felt hesitant about needing every program that writes to disk to need to use it to correctly set the modify time but perhaps it is not as bad as I had imagined.
One question though, I do not see fs as part of the api in CC's zip file, how can I therefore modify fs.open?
Thanks a lot!
One question though, I do not see fs as part of the api in CC's zip file, how can I therefore modify fs.open?
Thanks a lot!
#6
Posted 03 April 2013 - 02:20 PM
Aedda, on 03 April 2013 - 01:43 PM, said:
One question though, I do not see fs as part of the api in CC's zip file, how can I therefore modify fs.open?
you will have to edit bios.lua or startup (computer) in order to make the changes available at startup
sence io is a wrapper of fs, your changes sould still work for the io api
#7
Posted 03 April 2013 - 02:21 PM
Thank you JokerRH!
Thank you also PixelToast!
Moderators you may do whatever with this thread, sorry for any trouble!
Thank you also PixelToast!
Moderators you may do whatever with this thread, sorry for any trouble!
Edited by Aedda, 03 April 2013 - 10:36 PM.
#8
Posted 05 April 2013 - 05:02 AM
You don't have to edit buios.lua or startup. os.loadAPI also works and gets called for apis already registered. Take a look at the turtle or peripheral files in the apis folder, they're good examples for a "decorating" api.
#9
Posted 05 April 2013 - 10:11 PM
yeah, or just put a fs file in /rom/apis (given you have rom access).
quick suggestion:
And yes, i use semicola at the end of lines in lua. that IS valid syntax and looks cleaner IMO. you can just leave them out though
quick suggestion:
local nativefs = fs; local f = getfenv(); for k, v in pairs(fs) do f[k] = v; end function open(name, mode) -- whatever return nativefs.open(name, mode); end
And yes, i use semicola at the end of lines in lua. that IS valid syntax and looks cleaner IMO. you can just leave them out though
#10
Posted 12 April 2013 - 06:10 AM
You could over ride the function by doing like so:
local nativefs = fs; local open function(name, mode) --Do stuff; nativefs.open(name, mode); end _G["fs"]["open"] = open; --This will make it so you do not need to change any files in rom or the bios.
#11
Posted 16 September 2014 - 08:20 AM
Is this seriously the only solution we have to this problem? What a terrible state! Sorry to necromance but I think it's really important to be able to know file ages. For example, in JVML-JIT, I'd really like to be able to cache JIT'd java->lua code but I can't do that if I don't know if the .class file is newer than my cache file. And obviously class files aren't something that I can just tack a date to the beginning of, especially since they're not generated in computercraft.
And there's endless use cases for file ages. Really anything that has to do processing on a per-file basis could greatly benefit from being able to hold off on files whose age says it doesn't need to be re-processed.
And there's endless use cases for file ages. Really anything that has to do processing on a per-file basis could greatly benefit from being able to hold off on files whose age says it doesn't need to be re-processed.
#12
Posted 16 September 2014 - 01:42 PM
ElvishJerricco, on 16 September 2014 - 08:20 AM, said:
Is this seriously the only solution we have to this problem? What a terrible state! Sorry to necromance but I think it's really important to be able to know file ages. For example, in JVML-JIT, I'd really like to be able to cache JIT'd java->lua code but I can't do that if I don't know if the .class file is newer than my cache file. And obviously class files aren't something that I can just tack a date to the beginning of, especially since they're not generated in computercraft.
And there's endless use cases for file ages. Really anything that has to do processing on a per-file basis could greatly benefit from being able to hold off on files whose age says it doesn't need to be re-processed.
And there's endless use cases for file ages. Really anything that has to do processing on a per-file basis could greatly benefit from being able to hold off on files whose age says it doesn't need to be re-processed.
1st of all, this isn't a "problem".
2nd of all, you can easily do this yourself, as proven above.
So let the dead rest in peace.
#13
Posted 16 September 2014 - 02:04 PM
The solutions provided above are for saving "file attributes" relating to files written by ComputerCraft. While they could be expanded on to create something suitable, as they are they don't really apply to class files.
It's not gonna change though, so I can only suggest writing an additional class file that writes a text file containing time stamps for all class files, and run that through your host OS's copy of the JRE. Have fun if you're working in a server environment.
It's not gonna change though, so I can only suggest writing an additional class file that writes a text file containing time stamps for all class files, and run that through your host OS's copy of the JRE. Have fun if you're working in a server environment.
#14
Posted 16 September 2014 - 05:12 PM
As suggested above, the solution to the "problem" as it relates to ComputerCraft has been given. Let the dead rest in peace.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users