nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OD not updating timestamps on target

Auli2

Hi,

We are doing the DCRs using filelist based deployment with following settings -

registryPatchChecking="yes" on receiver
transaction="yes"
<transferRules doDeletes="yes" />
<comparisonRules dateDifferent="yes" revert="no" ignoreAcls="yes" ignoreModes="yes" ignoreUser="yes" ignoreGroup="yes" checksumCompare="yes" />
<permissionRules amask="" omask="" directory="0755" file="0644" group="ABC" user="ABC" changeAccess="" setAccess="" />

The content is getting updated correctly at the target but the files are showing the timestamp of the previous version. And this behaviour is intermittent.

Any pointers will be appreciated.

Find more posts tagged with

Comments

ISCBorisB

Hi,

We are doing the DCRs using filelist based deployment with following settings -

registryPatchChecking="yes" on receiver
transaction="yes"
<transferRules doDeletes="yes" />
<comparisonRules dateDifferent="yes" revert="no" ignoreAcls="yes" ignoreModes="yes" ignoreUser="yes" ignoreGroup="yes" checksumCompare="yes" />
<permissionRules amask="" omask="" directory="0755" file="0644" group="ABC" user="ABC" changeAccess="" setAccess="" />

The content is getting updated correctly at the target but the files are showing the timestamp of the previous version. And this behaviour is intermittent.

Any pointers will be appreciated.

Target timestamp setting is to a degree determined by Comparison Rule "applySourceFileTime". The default is "Yes".

So, check source timestamps of the Files in your List. If some of them were not modified between deployments they
will be deployed still, Target timestamp will stay the same though - identical to source.

Auli2

Thanks for the reply Boris.
We are not using applySourceFileTime attribute.
The issue reported is -
User edited two DCRs in the same directory inside templatedata and then submitted them using a workflow which deploys the DCRs to target server.
At the target side there is a application running that updates content on site based on timestamp changes.
Now, for both the DCRs, updated content was reflected on the target but one of them still shows the timestamp of the previous version. As a result, its content is not updated on the site.

Am I missing something or I have to use applySourceFileTime=No attribute? Also, it will set the target server deployment timestamp on the files, right.

ISCBorisB

We are not using applySourceFileTime attribute...

Yes you do - by default. As I pointed out, the default is "Yes".

Updated content was reflected on the target but [...] still shows the timestamp of the previous version

This is next to impossible to believe. Whoever reported this is IMO mistaken. Ignore your custom processing for a moment.
Compare Source/Target DCRs time stamps. Make sure that you compare exact Target Workarea Location, the one that is
set in OD Deployment Configuration.

I do not doubt that you have some issue here. Chances are overwhelming though that this is an issue of your processing application
rather than Open Deploy + Unix(!) modifying Files without changing timestamp.

...or I have to use applySourceFileTime=No...

This is certainly up to you to decide. That said, I do not think you have
to lose *real* content modification time in this manner, see my note above.

Migrateduser

It almost sounds like the deployment is taking place before the submit in the workflow. Can you share your workflow code?

Here is a setup that I use for file based deployments.

[PHP]

[/PHP]

The rmReadOnly property may help you out.

nipper

It almost sounds like the deployment is taking place before the submit in the workflow. Can you share your workflow code?

The other possibility is a cache issue. If you are using the cached mount then the Staging may not be updated before the deploy happens (assuming you deploy from Staging not Workarea)

The other issue I have seen is with TS running on a SAN environment. That can take minutes for a file to be locked into the Staging area. It is quite common that, when TS is on a SAN, and you have a deploy from Staging right after Submit, old data gets pushed.

You can also try running the deploy from the command line to see if this is an issue. If the workflow is the culprit, the deploy will be correct

Migrateduser

The interesting thing that Auli2 mentions is that the file gets changed, but not the changed timestamp. Which, I agree as ISCBorisB indicated, seems impossible to believe.

Auli2

Deployment is taking place from Staging after the files are submitted to Staging.
Also, as per the guide, rmReadOnly is for Windows while we are working on Unix environment.
We were also investigating the issue on the same lines as Andy has suggested and tried using /.iwmnt istead of /iwmnt but the target server file has the updated content. Its only the modified timestamp that is of the previous version.

nipper

Deployment is taking place from Staging after the files are submitted to Staging.
Also, as per the guide, rmReadOnly is for Windows while we are working on Unix environment.
We were also investigating the issue on the same lines as Andy has suggested and tried using /.iwmnt istead of /iwmnt but the target server file has the updated content. Its only the modified timestamp that is of the previous version.

Actually I bet it is the caching issue

This is similar to something I ran into several years ago.

Unix, deploy from Staging right after submit. Files came up short. Net result was that the deploy read the attributes of the file first (before the submit was committed), got the file size at 1850 bytes, deploy started, only deploying 1850 bytes of the file that finally got committed (which was larger).

Pain in the a$$ to debug. Maybe Auli2 is not crazy after all.

Auli2

If you bet it Andy then it must be right Smiley Happy

To counter the caching issue, we have also tried to put a sleep of 30 seconds after the file is submitted to Staging and before the deployment starts. But it doesnt solve the problem.

Using /.imnt is the solution? Any suggestions.

nipper

Run a deploy from the command line without the workflow, just on a file that has the old data. Does it get updated ?

ISCBorisB

Actually I bet it is the caching issue

This is similar to something I ran into several years ago.

Unix, deploy from Staging right after submit. Files came up short. Net result was that the deploy read the attributes of the file first (before the submit was committed), got the file size at 1850 bytes, deploy started, only deploying 1850 bytes of the file that finally got committed (which was larger).

Pain in the a$$ to debug. Maybe Auli2 is not crazy after all.

Cached mount or not, the very fact that updated Content is already visible indicates that TS I/O Caches have been already flushed.
It's very hard to believe that at this point last modification time ( -lT ) is not updated still.

nipper

Cached mount or not, the very fact that updated Content is already visible indicates that TS I/O Caches have been already flushed.
It's very hard to believe that at this point last modification time ( -lT ) is not updated still.

Not really. Because I saw that happen in a very similar way (with TS 6.5)

The submit happened. Staging still has old copy, Deploy task starts. OD 1st reads the attributes from the file (size, date, etc) cache gets cleared, OD opens the file and starts reading. Transports the file with the (old) attributes. I lived this puppy and was extremely difficult to nail down.

Auli2

Also consider that its a intermittent issue. This is not with every deployment. In fact, in the same deployment, one DCR that gets submitted first to Staging has the correct timestamp but the later one has the older timestamp.

I will try the option suggested by Andy and post the results.

nipper

Is your TeamSite repository on a physical disk connected to the server or are you using some sort of network storage ? I know of 1 customer that has had serious issues with NAS.

Auli2

Our Teamsite has physical disk connected to the server and we don't use network storage.

Auli2

I tried several deployments from the command line and they went through fine.
Any solution from the workflow?

ISCBorisB

I tried several deployments from the command line and they went through fine.
Any solution from the workflow?

I recall seeing contradictory references to the I/O Cache flushing frequency.
It is (used to be?) around 60 seconds and was not configurable. So, for a good measure
test with 90 seconds delay between submission and Deploy.

Also, use Source non-caching mounting point explicitly. Use area="/.iwmnt/..." Format.
Avoid using area="//IWSERVER/..." Path Prefix altogether, that evaluates to "/iwmnt/".

Auli2

Finally changed the logic to pick files from workarea, now its working fine Smiley Happy