File has local-remote name clash

[Former Member]

I have a DC which will compile and deploy correctly, but will not appear onscreen when started up. Stranger yet, it works fine on our Dev system but not on our Acc system!

In the request logs, I see this message for just about every file in the web dynpro application:

SYNC (FAILED: File has local-remote name clash) ico12_f1.gif (C:\TEMP\CBS\78\.CACHE\1270\DCs\com.shell\sp\hr\tf\data_manipulation\_comp\src\mimes\Components\com.shell.teamflow.wd.uwlintegration.Uwl_Form_Comp\ico12_f1.gif)

.....

Tried so far:

• askng the developer to resync and redeploy

• rebuilding the DC in CBS

• reinitializing the SC in CBS

• restarted the NWDI server

Any ideas guys?

[Former Member]

Are the mentioned files readonly or writable on your filesystem?

[former_member185029]

Hi,

You can following options

1. Upload the local file forcefuly into DTR.

2. Remove local client (C:\Documents and Setting\<UserID>\.dtr and C:\Documents and Setting\<UserID>\.dtc)

The second option you should try if your local version is older than the dtr version.

Please let me know if you have problem.

Ashu

[Former Member]

My theory:

This problem occurs on Consolidation and not on Development, this means that the CBS is not copying the files in the DTR's active workspace correctly from dev to cons. A couple of restarts & rebuilds makes the immediate problem go away but the development team experiences this as an irratic but still recurring problem.

Do you agree with this? If so this would mean a <b>structural</b> error with NWDI and I will need to make an OSS note.

If not, then this is an <b>operational</b> problem and we are doing something wrong. Any more ideas?

[Former Member]

Hi Gareth,

sounds more like an operational problem, but I would have expected a restart of the CBS engine to resolve this.

A "local-remote name clash" means you have a local file with the same name as a remote file but where DTR does not recognize your local file as the same resource. This typically happens if two developers create a file with the same name and try to check it in. If this happens on CBS, especially below a directory named "CACHE" I suspect that the cache data has become invalid.

The cache directory is buildspace specific and CBS should only sync the sources from the DTR Workspaces for that buildspace so I don't think the problem is in some transport from dev to cons.

What I would try to resolve the problem: Stop the engine where CBS is running. Check that the CBS tempdir is really empty, if not delete everything manually. Restart the engine and check if it works.

Since you mention that this is irratic but recurring I would probably open an OSS message for clarification.

Regards,

Marc

[Former Member]

Guys,

Some extra info:

• The CBS cache files on our NWDI server are writable.

• A restart of the CBS service alone (not the whole machine) solves the issue. This remains our only (temporary) workaround.

• The contents of the CBS cache have the correct names/timestamps etc according to what should be in the DTR.

• We only have one developer working on one DC. Therefore no two developers check the same file in.

I have created an OSS message and will post any results.

[Former Member]

Results of the OSS note:

A general solution would be to switch CBS to mode "useClassicSync=false" to neglect local-remote name clashes.

This setting dsescribes how CBS communicates with DTR when doing syncs (i.e. in the classical way, as when doing sync from IDE, or in an enhanced way special for CBS needs). So of course it is preferable to use the sync mode specialized for CBS (actually with SP14 'false' will be the standard value when configuring via CTC Template Installer -and also for SR2 this is the recommended setting, cf. note 1031182). Consequence of using this setting is that known issues in CBS sync scenario will no longer show up.

Concerning long DC names the only restriction we are aware of

are on windows platform: Here file names (containing the root

path of CBS, the name of the configuration, the compartment name and

the DC name) must not exceed 256 signs. So being restrictive in DC name

length is in general preferable, details however depend also on the

length of the other emntioned parts.

For UNIX platforms there is no knwn restriction.

And actually having 'too long names' should lead to reproducible

effects (build/dpeloyment working in general -or not) -unless they

run against different platforms 'from time to time'.

[Former Member]

Remarks about out setup:

Our NWDI server has 4 J2EE server nodes, each running the CBS service

on a Windows environment. The CBS cache is set at the global server

level to point to the folder e:\data\cbs. Ie: all 4 server nodes are

using the same cache folder.

SAP Response:

There are no known limitations concerning running CBS on several nodes.

However your setting for all nodes to use the same cache folder is very

probably the reason for the observed behaviour: Each node should use a

different cache location, otherwise builds on different nodes might

'destroy' their caches (by mutually overwriting the other one's store).

So only running one node should resolve your issue -or running differentnodes, but each with a separate cache.

This was the real solution to this problem