Checkin & Publish workflow not updating file timestamps

The Checkin & Publish workflow for stories that already exist on the production server is causing files to be generated with their originally published timestamp.

Since we use a little bit of Mason on the production server to dynamically tie components together this causes problems: the Mason cache on the production server reads the same old timestamp, doesn't invalidate the cache and we see the old content instead of the newly published content.

Republishing said stories generates files with new timestamps but this is a two-step process where we would ideally prefer one.

What are other people doing to get around this kind of problem? Is there a way for the Checkin & Publish workflow to generate files with newer timestamps?

> The Checkin & Publish workflow for stories that already exist on the production server is causing files to be generated with their originally published timestamp. > > Since we use a little bit of Mason on the production server to dynamically tie components together this causes problems: the Mason cache on the production server reads the same old timestamp, doesn't invalidate the cache and we see the old content instead of the newly published content. > > Republishing said stories generates files with new timestamps but this is a two-step process where we would ideally prefer one. > > What are other people doing to get around this kind of problem? Is there a way for the Checkin & Publish workflow to generate files with newer timestamps?

So checkin publish resets the timestamps but republishing does not? That's weird. Which mover are you using? File system, FTP, SFTP, DAVů?

>> Republishing said stories generates files with new timestamps but >> this is a two-step process where we would ideally prefer one. >> >> What are other people doing to get around this kind of problem? Is >> there a way for the Checkin& Publish workflow to generate files >> with newer timestamps? > > So checkin publish resets the timestamps but republishing does not? > That's weird. Which mover are you using? File system, FTP, SFTP, > DAVů?

Sorry - maybe I messed up the details. Let's see if I can get this straight. This is what's happening:

1) Neither "Checkin & Publish" nor "Publish Now" will generate a file with a new timestamp. A file with the new content makes its way to the server but the existing timestamp is used.

2) Republishing generates files with new timestamps. This causes changes to content to be reflected immediately.

Essentially what we want is for either of the #1 use cases to generate files with new timestamps just like republishing.

We're using the built-in SFTP mover with bric_queued. FTP_UNLINK_BEFORE_MOVE is turned on.

> Sorry - maybe I messed up the details. Let's see if I can get this straight. This is what's happening: > > 1) Neither "Checkin & Publish" nor "Publish Now" will generate a file with a new timestamp. A file with the new content makes its way to the server but the existing timestamp is used. > > 2) Republishing generates files with new timestamps. This causes changes to content to be reflected immediately. > > Essentially what we want is for either of the #1 use cases to generate files with new timestamps just like republishing.

They should exhibit exactly the same behavior. Very weird.

> We're using the built-in SFTP mover with bric_queued. FTP_UNLINK_BEFORE_MOVE is turned on.

Try seeing if there is any clock skew between your Bricolage server and the end-point destination server.

-Michael

On Jul 16, 2011, at 11:13 AM, Matt Adams wrote: >>> Sorry - maybe I messed up the details. Let's see if I can get this straight. This is what's happening: >>> >>> 1) Neither "Checkin& Publish" nor "Publish Now" will generate a file with a new timestamp. A file with the new content makes its way to the server but the existing timestamp is used. >>> >>> 2) Republishing generates files with new timestamps. This causes changes to content to be reflected immediately. >>> >>> Essentially what we want is for either of the #1 use cases to generate files with new timestamps just like republishing. >> They should exhibit exactly the same behavior. Very weird. >> >>> We're using the built-in SFTP mover with bric_queued. FTP_UNLINK_BEFORE_MOVE is turned on. >> Here's the code: >> >> # Now, put the file on the server. >> my $dest_file = $fs->cat_file( >> $doc_root, unescape_uri substr $res->get_uri, 1 >> ); >> my $temp_dest = "$dest_file.tmp"; >> >> $sftp->unlink($temp_dest) if FTP_UNLINK_BEFORE_MOVE; >> $ssh2->scp_put($src, $temp_dest) or throw_gen( >> error => "Error putting file '$dest_file' on '$hn'", >> payload => join ' ', $ssh2->error >> ); >> $sftp->unlink($dest_file) if FTP_UNLINK_BEFORE_MOVE; >> $sftp->rename($temp_dest, $dest_file) or throw_gen( >> error => "Error renaming '$temp_dest' to '$dest_file' on '$hn'", >> payload => join ' ', $sftp->error >> ); >> >> >> It does nothing to adjust mtimes or anything. What happens if you turn off FTP_UNLINK_BEFORE_MOVE, just for the hell of it? >> >> David >>

> It does nothing to adjust mtimes or anything. What happens if you > turn off FTP_UNLINK_BEFORE_MOVE, just for the hell of it?

Publishing fails without this option.

Interestingly enough, it appears that Checkin & Publish is now working as expected. This leads me to suspect that there was a clock skew between the Bricolage server and end-point destination, as suggested by Michael.

>> It does nothing to adjust mtimes or anything. What happens if you >> turn off FTP_UNLINK_BEFORE_MOVE, just for the hell of it? > > Publishing fails without this option. > > Interestingly enough, it appears that Checkin & Publish is now working as expected. This leads me to suspect that there was a clock skew between the Bricolage server and end-point destination, as suggested by Michael.