Mailing List Archive

On Jul 16, 2011, at 10:50 AM, Matt Adams wrote:

> Hi,

Hi!

> 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…?

Best,

David

On 16/07/11 12:06 PM, David E. Wheeler wrote:

>> 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.


Thanks,

Matt
--
PO Box 393 Wabasca, AB T0G 2K0 780-891-3282 madams@phantomware.ca

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

Matt,

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
>>

--
Michael Herring
Information Technology Services
Web Developer
Denison University
740-587-6360
herringm@denison.edu

On 16/07/11 12:18 PM, David E. Wheeler wrote:

> 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.


Thanks guys,

Matt
--
Matt Adams
Radical Dynamic
www.radicaldynamic.com

On Jul 25, 2011, at 3:42 PM, Matt Adams wrote:

>> 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.

Yeah, that makes much more sense.

Best,

David