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

Hi Thilo, Quoting [Thilo Kielmann] (May 29 2009):

Date: Fri, 29 May 2009 15:15:23 +0200 From: Thilo Kielmann To: saga-rg@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.