I have a directory containing two files. f1 (<http://alcopop.org/~jon/repro2/src/blog/debgtd.html>) has 

    meta date="2008-07-02 14:13:17"

f2 (<http://alcopop.org/~jon/repro2/src/blog/moving.html>) has

    meta date="2008-07-02 21:04:21"

They have both been modified recently:

    >>> stat(f1)
    (33188, 459250L, 65027L, 1, 1000, 1000, 1686L, 1227967177, 1227966706, 1227966706)
    >>> stat(f2)
    (33188, 458868L, 65027L, 1, 1000, 1000, 938L, 1227967187, 1227966705, 1227966705)

Note that f1 is fractionally newer than f2 in terms of ctime and mtime, but f2 is much newer in terms of the meta information.

Another page includes them both via inline:

    inline pages="blog/*" show=5

The resulting page is rendered with f1 above f2, seemingly not using the meta directive information: <http://alcopop.org/~jon/repro2/dest/blog/>. The footer in the inline pages does use the correct time e.g. <em>Posted Wed 02 Jul 2008 14:13:17 BST</em>.

If I instead include them using creation_year in the pagespec, they are ordered correctly.

<http://alcopop.org/~jon/repro2/> contains the src used to reproduce this, the precise ikiwiki invocation (inside Makefile) and the results (dest).

-- [[users/Jon]]


> On Ikiwiki 2.53.3 (Debian Lenny), my inlines are also sorted using mtime
> by default -- despite what the [[documentation|/ikiwiki/directive/inline]]
> says -- but setting the supposed default sort order manually produces the
> correct results.  For example, the following inline sorts my blog
> entires using their meta date or ctime:
> 
>     inline pages="blog/*" show="10" sort="age"
> 
> I'll try to look at the code this weekend and see if age is really the
> default sort order.
> 
> -- [David A. Harding](http://dtrt.org), 2008-12-20

Here is the code. As you can see, sort="age" is equivilant to leaving
out the sort option. --[[Joey]] 

	if (exists $params{sort} && $params{sort} eq 'title') {
	        @list=sort { pagetitle(basename($a)) cmp pagetitle(basename($b)) } @list;
	}
	elsif (exists $params{sort} && $params{sort} eq 'mtime') {
	        @list=sort { $pagemtime{$b} <=> $pagemtime{$a} } @list;
	}
	elsif (! exists $params{sort} || $params{sort} eq 'age') {
	        @list=sort { $pagectime{$b} <=> $pagectime{$a} } @list;
	}
	else {
	        return sprintf(gettext("unknown sort type %s"), $params{sort});
	}

> On further testing, I find that the bug is limited to the first time
> creation time should be used and has nothing to do with setting the sort
> parameter. Revised steps to reproduce: --[David A.  Harding](http://dtrt.org), 2008-12-20
> 
> 1. Create pages that sort different by mtime and ctime
> 
> 2. inline pages="somepages/*"
> 
> 3. ikiwiki --setup setup_file
> 
> 4. Pages are output incorrectly in mtime order
> 
> 5. ikiwiki --setup setup_file
> 
> 6. Pages are output correctly in ctime order
> 
> 7. Create new page in somepages/, set its ctime to earlier than another
>    page in sompages/
> 
> 8. ikiwiki --setup setup_file
> 
> 9. All previously sorted pages output correctly in ctime order but new
>    page is output incorrectly at the top as if its mtime was its ctime
> 
> 10. ikiwiki --setup setup_file
> 
> 11. All pages, including new page, are output correctly in ctime order

You're confusing ctime and creation time. This is perhaps not suprising, as
ikiwiki uses the term 'ctime' to refer to creation time. However, the unix
ctime value is not the same thing. Unix ctime can change if a file changes
owner, or in some cases, permissions. Unix ctime also always changes
when the file is modified. Ikiwiki wants a first creation date of the file,
and it accomplishes this by recording the initial ctime of a file the first
time it processes it, and *preserving* that creation time forever, ignoring
later ctime changes.

I suspect that this, coupled with the fact that ikiwiki sorts newest pages
first, explains everything you describe. If not, please send me a shell script
test case I can run, as instructions like "Create pages that sort different by
mtime and ctime" are not ones that I know how to follow (given that touch sets
*both*). --[[Joey]]