File_system: support for file modification timestamps

[cnuke]

By now having support for something like st_ctim and st_mtim sounds reasonable. Adding this feature would first of all involve extending File_system::Status as well as adding the required functionality to each file system or rather enabling the usage by tapping into the existing API (e.g. rump_fs) and probably the layers above (VFS). I am not sure if it is actually necessary to support it in all pseudo file system (or even ram_fs for that matter) but at least supporting in the ones used for persistent storage would be nice.

[cnuke]

The plan for implementing the functionality is as follows:

1. Add a Timestamp member to File_system::Status which saves the modification time as signed 64bit integer. If a more structured type is needed, we will introduce convenience utilities.
2. Add a new packet type to the File_system session called WRITE_TIMESTAMP which allows clients to update the modification timestamp of a node. The rough plan is to send this packet whenenver a “dirty” node is closed or before a SYNC packets but that's up to the client, e.g. VFS/libc.

Setting the modification time of a node should be a deliberate decision of the client rather than an implicit side-effect of the file system provider, which may or may not has access to a time source.

Afterwards we'll deal with the VFS and libc side of things.

[nfeske]

Thank you for capturing the outcome of our offline discussion, @cnuke.

[cnuke]

My file_system_modtime__wip branch contains the first sketch (be warned I haven't even tried to compile it yet).

[nfeske]

The commits already very nice. Please see my inline comments.

[cnuke]

I updated my wip branch. It now contains a semi-functioning implementation, open issue to consider:

• For one it relies on doing the right thing at the client-side, i.e., calling utimes(). This does not happen a newly created files (that includes cping as well) as that is normally the job of the kernel .
• Apart from the that, in case of a libc component, the modification time always gets updated whenever _vfs_sync() is executed. Since we do not track if a file was opened r/o or rather if it was modified (the same is true for noux) we now change it accidently as a side-effect.
• We normally discourage writing to directories but we now might still update their modification time.
• Sophisticated VFS plugins, e.g., vfs_rump, might ignore our attempt to set the modification time and will change it own their own.

So far I will ignore the last two points and focus on the first two.

[ehmry]

The eager sync has already been identified as a unnecessary and don't see any problems with skipping it for unmodified files.

[cnuke]

Yes and the tracking of unmodified files is the thing missing so far.

[cnuke]

I've force pushed the branch again and it now contains commits that address the first two points of my previous post. Together with some small adjustments in the *genodians.org` appliance, lighttpd serves resources with the proper modification time now. I'll work on cleaning it up for staging next week.

[cnuke]

The current WIP state is now live on genodians.org.

[cnuke]

Running it on genodians.org revealed a bug in the current implementation (I didn't catch the Insufficient_buffer exception of the Fs_file_system in the libc) and I changed it to use the same mechanism as the sync packet now. That being said, I reverted genodians.org back to an older version b/c there are still some issue left.

[cnuke]

I put the commits on top of the current master branch and they are live again on genodians.org.

@m-stein you may give thunderbird's RSS tool a try.

[m-stein]

@cnuke Ah thanks!

[m-stein]

@cnuke Seems to work - thanks a lot!

[cnuke]

And the mtime commits are off again, there are apparently still some problems left (genodians.org sometimes still gets stuck, setting verbose="yes" in noux seems to make it more reliable while interactive usage works fine).

[nfeske]

Fixed in master.