[SAGA-RG] missing(?) method reporting last modification time

[Andre Merzky]

Hi Thilo, 

Quoting [Thilo Kielmann] (May 29 2009):
> Date: Fri, 29 May 2009 15:15:23 +0200
> From: Thilo Kielmann <kielmann at cs.vu.nl>
> To: saga-rg at ogf.org
> Subject: [SAGA-RG] missing(?) method reporting last modification time
> 
> 
> Folks,
> 
> within our group we are currently delving into issues with accessing
> remote file systems. What strikes us is that such access is SLOW.
> As such, it would be very beneficial if one could find out when (and
> thus whether) a remote file or directory has been modified.
> 
> While returning this piece of information sounds to be "trivial", it strikes
> us that the SAGA spec has no such call in the name space package (where files
> reside).
> 
> In POSIX terms, this is the info returned by the stat system call
> (see: man 2 stat), with the st_mtime parameter.
> 
> In Java, files have a method lastmodified().
> 
> Both POSIX and Java report the time in milliseconds since 01/01/1970 (epoch).
> 
> Of course, it looks like nobody has ever been thinking about such a use case,
> but here we are! 

This is exactly why it was left out: no explicit use case...
The agreement back then was, IIRC, to introduce a full
stat() method in version 2 if later use cases require it.

Thus, if you consider to add mtime, then please also
consider to add the other time stamps.  From lstat(2):

 struct timespec st_atimespec;     /* time of last access */
 struct timespec st_mtimespec;     /* time of last data modification */
 struct timespec st_ctimespec;     /* time of last status change */
 struct timespec st_birthtimespec; /* time of file creation(birth) */

Related to that discussion was, BTW, the question whether
find() should support metadata criteria - at the moment,
find only operates on entry names, and patterns thereof.  I
am not saying that this should be extented, but you may want
to discuss it in respect to your use case...


> Our feeling is that the last modification time is very
> essential meta data about files, so such a call should certainly be there.
> With our current problem certainly not being the only use case for finding
> out how old/new a given file or directory is...
> 
> Our favourite proposal is to add a method that returns the last modification
> time to both ns_entry and ns_directory as this makes sense with physical as 
> well as with logical (replicated) files.

Probably makes sense.  Not all namespace backends will be
able to report timestamps I guess, but that's live.

I'd suggest to keep the method calls symmetric to
file.get_size(), in terms of semantics, error conditions,
etc.  get_size() is the only stat info we have included in
the core.  Well, apart from permission flags, which are
handled by the permissions interface though.

So, would something like

  get_atime ()
  get_mtime ()
  get_ctime ()
  get_btime ()

work for you folx?  I realize that this differs from what
Sylvain's group added to JSAGA... :-/


Hmm, sorry for leeting this mail grow rather long, but
please allow me to ramble on...

We have been discussing the attribute interface again
lately, in particular in respect to typed attributes.  I'll
post a more detailed proposal later next week, but for now,
we think it might look similar to the task.get_result we
have in C++, i.e. have type-templetized attribute
setters/getters.  For a time attributes, this would actually
allow for convenient conversions, like:

  int   ms_since_epoch  = ns_entry.get_attribute <long>        ("mtime");
  struct tm       spec  = ns_entry.get_attribute <struct tm>   ("mtime");
  std::string     time  = ns_entry.get_attribute <std::string> ("mtime");
  bool            check = ns_entry.get_attribute <bool>        ("mtime");

The last one, bool, would throw because there is no sensible
conversion.  Time as string would return a ctime(3)
formatted string, in C++.

Again, I am not saying that this is how it should be
rendered (and also we are not sure if conversion is actually
a good thing to have on the attrib interface), but you might
want to consider to use the attrib interface for stat like
information.  file size would then move into the attribs as
well I guess.


> Any reactions/objections ???

About procedure: do you consider that an errata for GFD.90,
or rather to be input to the next version?  

Note that typed attributes would be within the scope of the
current spec, as that is left to the language bindings.
However, attributes on ns_entry, and/or get_mtime etc., would
need spec amendment.

Best, Andre.


> Thilo Kielmann

-- 
Nothing is ever easy.