Jump to content




[1.53] Api function for file modify date or age


13 replies to this topic

#1 Aedda

  • Members
  • 7 posts

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?

#2 AndreWalia

  • Members
  • 294 posts
  • LocationSt.Louis, MO

Posted 03 April 2013 - 12:21 PM

You could do this your own by modifying the edit and some other stuff

#3 Dlcruz129

    What's a Lua?

  • Members
  • 1,423 posts

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 Aedda

  • Members
  • 7 posts

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!

#5 JokerRH

  • Members
  • 147 posts

Posted 03 April 2013 - 02:03 PM

View PostAedda, 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?

nativeopen = fs.open
function fs.open(path, mode)
  --Additional code here

  return nativeopen(path, mode)
end


#6 PixelToast

  • Signature Abuser
  • 2,265 posts
  • Location3232235883

Posted 03 April 2013 - 02:20 PM

View PostAedda, 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?
the fs api is built in to computercraft
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 Aedda

  • Members
  • 7 posts

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!

Edited by Aedda, 03 April 2013 - 10:36 PM.


#8 Xfel

    Peripheral Designer

  • Members
  • 515 posts

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 Kilobyte

  • Members
  • 122 posts

Posted 05 April 2013 - 10:11 PM

yeah, or just put a fs file in /rom/apis (given you have rom access).
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 :P

#10 Jarle212

  • Members
  • 198 posts
  • LocationNorway

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 ElvishJerricco

  • Members
  • 803 posts

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.

#12 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 16 September 2014 - 01:42 PM

View PostElvishJerricco, 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.

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 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

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.

#14 Cranium

    Ninja Scripter

  • Moderators
  • 4,031 posts
  • LocationLincoln, Nebraska

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