Mailing List Archive: Bricolage: users

Checkin & Publish workflow not updating file timestamps

Index | Next | Previous | View Threaded

matt.adams at radicaldynamic

Jul 16, 2011, 10:50 AM

Post #1 of 7 (942 views)
Permalink

Checkin & Publish workflow not updating file timestamps

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?

Thanks,

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

david at kineticode

Jul 16, 2011, 11:06 AM

Post #2 of 7 (902 views)
Permalink

Re: Checkin & Publish workflow not updating file timestamps [In reply to]

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

madams at phantomware

Jul 16, 2011, 11:13 AM

Post #3 of 7 (900 views)
Permalink

Re: Checkin & Publish workflow not updating file timestamps [In reply to]

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 [at] phantomware

david at kineticode

Jul 16, 2011, 11:18 AM

Post #4 of 7 (903 views)
Permalink

Re: Checkin & Publish workflow not updating file timestamps [In reply to]

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

herringm at denison

Jul 19, 2011, 8:17 AM

Post #5 of 7 (884 views)
Permalink

Re: Checkin & Publish workflow not updating file timestamps [In reply to]

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 [at] denison

matt.adams at radicaldynamic

Jul 25, 2011, 3:42 PM

Post #6 of 7 (851 views)
Permalink

Re: Checkin & Publish workflow not updating file timestamps [In reply to]

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

david at kineticode

Jul 25, 2011, 4:44 PM

Post #7 of 7 (854 views)
Permalink

Re: Checkin & Publish workflow not updating file timestamps [In reply to]

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads