Forum OpenACS Development: What is the proper behavior of folder modification times in file-storage?

The current code is somewhat inconsistent in when it modifies the folder modification time.  I want to fix that, but first we have to decide how it should behave.  There are (at least) two options:  the way UNIX (and I believe Windows) does it, and the way non-technical users expect it to work.

The way UNIX and other OS's work is that they only update the folder (directory) modification time when the folder is actually modified.  That means if you create, delete or rename a file, the folder time is updated, but not if you edit an existing file.  In addition, only the local folder is updated.

The way users expect file-storage to behave (at Sloan, anyway) is that the folder modification time will be updated whenever there is something new in that folder.  In their minds, that includes new versions of existing files.  They also want the times to be modified all the way up to the root of the tree, so at any level they can look at the times to see if there is anything new "down there".

The current code does propogate the changes up the tree, but it does not update the time for all the operations it should and it does not do it for new versions of existing files.

I think the user POV is more logical to the average user of an OpenACS website than the UNIX approach, but I'd like to open this up for discussion.  Thoughts, anyone?

I think the user point of view is prefered, personally. The user is king.
As you point out, though, windows does it the same way as Unix (and Mac OS X) and most users know about computers from using either a Windows PC or a Mac.

Both of which don't display modification times by default for folders, BTW ...

Anyway I'm not sure I agree with the assessment that "users expect it to work differently than Windows or Mac (as well as Unix)"  Obviously someone at Sloan does but that's different.

I think we can split this into two issues:

1.  Folder modification times aren't quite right.  The time isn't updated when a file is deleted, which is wrong, and it looks like there is already code there to update it on a new version of a file which is not working for me (and depending on what we decide here could be the wrong thing to do entirely).

2.  Our users (and, I believe, most users) want to be able to tell at a glance whether there is anything new in a folder (or anywhere below it) without having to click through.  They would be mostly interested in new files and new versions of existing files;  I don't think they care too much about moved, renamed or even deleted files.

There is a "new" image which is supposed to indicate newness, but it is on all the time for everything right now.  Even if it was working correctly it still wouldn't be too useful to us because it's based on "new within N days", and what we really want is "new since you last looked".  But it's better than nothing, and my first pass on this issue could be just to make all of this work the way it's supposed to, which would be to make the folder modification times work like they do in UNIX, and have the new image show up for files which have changed and folders which contain changed files.

However... I believe that showing the "last modified" column to all users is going to be generally confusing.  Especially if the folder time shows that something has changed, maybe a file was deleted, but the folder "new" image isn't showing because it's not really new content.  So along with making it all work, I think it should be possible, by package parameter, to suppress the "last modified" column.

Thoughts?  Is there a better way to approach this?

Secondly, I'd like to think about making the new image work on a per-user basis.  This would also have to be parameterized since it's somewhat costly and not everyone needs it.  Don, you implemented this on Sloanspace and you were worried about performance - how did it turn out in the end?  I know it worked, but was it as expensive as you had feared?

No, it wasn't all that expensive in the end though a fair amount of data was kept around.  I did it for forums, not file-storage and coincidently I've been wanting to resurrect it for forums and have thought about it for file storage, too.

The datamodel I used to implement this for ACES forums would work for tracking "new" for OpenACS forums, at least the strategy would work.  I think it should be parameterizable by forums package instance.  I think for ACES I may've made it parameterizable by forum.

I've not looked at what it would take to do this for file storage.

And of course the holy grail would be a generalized service that could flag any unread content of any type heh heh heh.

As you know from earlier e-mail I'm all in favor of supressing the timestamp for folders if that makes things less confusing for users.

But I think you're on the right track with the idea of making "new" useful.