Zenphoto
The simpler media website CMS
ZenphotoThe simpler media website CMS
Forum search only. You might also want to search on the main site's user guide.
Your support helps pay for this server, and helps development of zenphoto. Thank you!
Visit the donations page
Comments
Nightly build is found here: http://www.zenphoto.org/files/nightly/
Is the "date" column also at fault here?
Access: 2007-12-12 14:16:26.000000000 -0800
Modify: 2006-03-23 10:44:26.000000000 -0800
Change: 2006-11-07 10:16:52.000000000 -0800
Zenphoto is identifying files by their ctime, rather than their mtime. It seems to me that mtime is a more useful time for zenphoto to use, because it represents (most likely) the actual modification date of the file. File restores, etc. can alter the ctime but usually preserve the mtime. Plus you can manually change mtime using 'touch', which makes it all the more useful if you want to keep your albums properly date-tagged.
I'd call this a bug, personally. What do you think?
I then ran the following update to set the albums to the appropriate date for the images (so as to sort properly in the gallery):
`update albums, (select albumid, max(mtime) as mtime, max(date) as date from images group by albumid) as i
set albums.mtime = i.mtime, albums.date = i.date
where albums.id = i.albumid`
The end result is just what I wanted. Everything's dated appropriately, and the gallery sorts automatically in chronological order. Beautiful!
I guess now I need to figure out how to put these changes into the subversion repository... Any chance someone else wants to do it for me? Please?
`filemtime` is beign used to try to detect that an image has "changed" somehow and we should refresh the database with new image information. This is why I suggested dropping the mtime field--it would cause a refresh of the db.
`filectime` is used as a default setting for the `date` field in the database. It is of course argueable if this is the correct choice, but it is a first guess. It is more likely to be the data the file was uploaded, which is an approximation for the date shot. If the image has EXIF or IPTC data that includes date information, then that is the value that will be put in the `date` field. The `date` field's intent is that it is the shooting date of the image.
So, what you are in effect doing with your change is to order your images by the date they were last touched. An interesting concept, but maybe not all that generally useful.
The SVN has some new fields you can use for sort order. Perhaps you could consider sorting your images and albums by ID. This will put them in the order they were created in the database--also a close approximation of the upload order.
I think ctime is a problematic way to approximate the date of a picture's creation, as ctime is an unreliable measure of a file's creation date. It's simply a system representation of the date that the inode for the file was created.
While some operating systems (MacOS X, for example) have a separate "date created" timestamp on files that is separate from the date the particular instance of the file was created, most Unixes have no equivalent. We can only tell the date of a distinct instance of a file on a given filesystem.
In MOST cases, mtime should match ctime in the case of an uploaded file (it was last modified and created when copied from the user's camera, and again, modified and uploaded at the same time). Unless the core file is updated on the server (an odd thing to do once it's already in a photo gallery), the mtime and ctime ought never to be out of sync.
So, from a functional perspective, mtime seems more useful because it can be reliably maintained through backup and restore processes and is also user-modifiable, so users can sort their photos as they wish. And in most cases, mtime and ctime would be in sync, anyhow, so from a general usability standpoint, the gallery would work as expected.
In my case, I had to recover my files from a backup, so each was created as a new inode (on a new filesystem, for that matter), with updated ctimes. The files themselves were last modified on upload date (the restore process correctly maintained all the file metadata it could).
Of course, if EXIF data is present, none of this is an issue. Many of my files lack this information because they went through batch changes from RAW to JPEG to simplify uploading, and the program I used didn't maintain that metadata. Now I know better.