File attributes not updating on Serena Network drive

Hi,

we are using the Serena Network in our office to connect to our IBM host.

When I lock a file for editing (right click on the file, Serena Network, Lock Component) the file attribute READ ONLY gets off.

Although I right click on the file in DO 10.5.2.0, the file attribute won't be updated and READ ONLY is still on. In Explorer the file attribute READ ONLY is off automatically.

Serena01.png shows the file attributes BEFORE I right click on the file (L1NGAU2.csr) in DO(!) and lock the component .

Serena02.png shows the file attributes AFTER "locking" the file. The file attribute READ ONLY is on in DO and off (correct) in Explorer.

When I select "unlock" (=> read-only on) - the same. Updates on Explorer, no update in DO.
Also when I lock/unlock in Explorer, no updates in DO.

When I refresh the directory in DO the attributes are correct (with Windows 7 now - was not in XP!).

Are there any settings in the preferences of DO to avoid this or to get the correct file attributes? I've looked around but ...

Thanks a lot!

PS:

DO is not in replacement mode, etc. (to dangerous in the office).

Sorry but with the new Windows 7 snipping tool I wasn't able to make screen shots with right click open windows.




The first thing to do is everything in the Changes to folders are not being detected FAQ.

Thanks Leo,

the settings in Preferences are as it should be in your link above.

Should I try to detect it with DebugView or ProcessMonitor?

How can I display the additional columns that Serena Networks adds to the Explorer View (e.g. "CompStatus" - see screen shot above)? I can't see them in DO.

If it's in the guide, it's worth trying.

Columns added by shell extensions may appear in the 'Other' category of columns, when in a folder which supports them, but it also depends on how they have been added to Explorer.

PHPBB_IMPORT_WARNING CODE_NEAR_LI

Hi,

I just had time to analyze the problem with DebugView:

Analyzed with DO 10.5.2.0, Windows 7 64bit.

[ul]Without DebugView (as reported above):

[li] Re-bootet PC, started Explorer, connect to Serena Network, started DO
=> In Explorer + DO: attribute "Read Only" set[/li]
[li] In DO, right click on file, Serena Network, Lock Component
=> In Explorer: attribute "Read Only" not set (ok)
=> In DO: attribute "Read Only" set (not ok)[/li]
[li] In DO, Refresh of directory
=> In DO: attribute "Read Only" not set (ok)[/li][/ul]

In 3270 on IBM host I have changed the file back to unlock.

2.

[ul]With DebugView and "notify_debug = true" enabled:

[li] Re-bootet PC, started Explorer, connect to Serena Network, started DO
=> In Explorer + DO: attribute "Read Only" set[/li]
[li] In DO: changed "notify_debug = true"[/li]
[li] Started DebugView[/li]
[li] In DO, right click on file, Serena Network, Lock Component
=> In Explorer: attribute "Read Only" not set (ok)
=> In DO: attribute "Read Only" set (not ok)[/li]
[li] In DO, Refresh of directory
=> In DO: attribute "Read Only" not set (ok)[/li][/ul]

This is the only content around "CMNP" I've found in the log file of DebugView.

The file changed is inside the directory "\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\CSR"

00000104 17.07194710 [2308] [4532] dopus: Notify 00000000048B2220 Returned 0 bytes, error 0 00000105 17.07258987 [2308] [5616] dopus: Change 153 on \\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\CSR 00000106 32.44236374 [2308] [4532] dopus: Notify 00000000048B23C0 Returned 84 bytes, error 0

I think you will know what "change 153" means.

Note: The change of "notify_debug" seams to refresh the current folder!

In 3270 on IBM host I have changed the file back to unlock.

[ul]With DebugView and "notify_debug = true" and "shellchange_debug = true" enabled:

[li] Re-bootet PC, started Explorer, connect to Serena Network, started DO
=> In Explorer + DO: attribute "Read Only" set[/li]
[li] In DO: changed "notify_debug = true" and "shellchange_debug = true"[/li]
[li] Started DebugView[/li]
[li] In DO, right click on file, Serena Network, Lock Component
=> In Explorer: attribute "Read Only" not set (ok)
=> In DO: attribute "Read Only" not set (ok)[/li][/ul]

00000193	19.06785583	[2316] [2256] dopus: Notify 0000000004A527D0 Returned 0 bytes, error 0	
00000194	19.06850624	[2316] [6092] dopus: Change 153 on \\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\CSR	
00000195	19.59596062	[2316] [2256] dopus: ShellChange: 00000000042834C0, 3	
00000196	19.59603310	[2316] [2256] dopus: ShellChange: dwEvent = 2000	
00000197	19.59621048	[2316] [2256] dopus: ShellChange: update item = \\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\CSR\L1NGAU2.csr	
00000198	19.59626389	[2316] [2256] dopus: ShellChange: 00000000042834C0, 3	
00000199	19.59633446	[2316] [2256] dopus: ShellChange: dwEvent = 2000	
00000200	19.59724998	[2316] [2256] dopus: ShellChange: update item = \\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\CSR\L1NGAU2.csr	
00000201	19.59729385	[2316] [2256] dopus: ShellChange: 00000000042834C0, 3	
00000202	19.59731674	[2316] [2256] dopus: ShellChange: dwEvent = 2000	
00000203	19.59751892	[2316] [2256] dopus: ShellChange: update item = \\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\!\L1NGAU2.csr	
00000204	22.44367599	[2316] [2256] dopus: Notify 0000000004A523C0 Returned 78 bytes, error 0	

When "shellchange_debug = true" is enabled, the attribute of the file changes! When the debug option is false - I get no update of the file attribute in DO!

When I try "Unlock component" (=> "Read Only" set) with "shellchange_debug = true" , the system has problems. The attribute "Read Only" won't be set in Explorer / DO !

00000269	47.99475861	[2316] [2256] dopus: Notify 0000000004A527D0 Returned 0 bytes, error 0	
00000270	47.99682617	[2316] [6092] dopus: Change 153 on \\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\CSR	
00000271	48.50512314	[2316] [2256] dopus: ShellChange: 00000000042837C0, 3	
00000272	48.50518799	[2316] [2256] dopus: ShellChange: dwEvent = 2000	
00000273	48.50537491	[2316] [2256] dopus: ShellChange: update item = \\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\CSR\L1NGAU2.csr	
00000274	48.50572968	[2316] [2256] dopus: ShellChange: 00000000042837C0, 3	
00000275	48.50577927	[2316] [2256] dopus: ShellChange: dwEvent = 2000	
00000276	48.50733566	[2316] [2256] dopus: ShellChange: update item = \\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\CSR\L1NGAU2.csr	
00000277	48.50778198	[2316] [2256] dopus: ShellChange: 00000000042837C0, 3	
00000278	48.50810623	[2316] [2256] dopus: ShellChange: dwEvent = 2000	
00000279	48.50827026	[2316] [2256] dopus: ShellChange: update item = \\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\!\L1NGAU2.csr	
00000280	54.52704239	[2316] [2256] dopus: Notify 0000000004A523C0 Returned 90 bytes, error 0	

I tried all 3 possibilities multiple times - for 3 hours now. Always the same - incl. the troubles when using "shellchange_debug = true"!

Mysterious so far - and I hope that helps.

Hi,

is it please possible to get a reply if it is possible to fix the problem why Explorer shows the correct file attribute "read-only" and DO does it not?

Thanks a lot!

I suspect what's happening is that the drive is generating change events before the change has actually taken place, and then if the file attributes are inspected too quickly the old ones are still returned. I can't tell that for sure, but it's the only thing I can think of which makes sense.

First, toggling shellchange_debug changes nothing except that Opus will print some extra debugging information to DebugView. I've checked the code and that is literally the only thing which will change. The only difference that should make is to make Opus process events slightly slower, which leads to my theory, above.

Toggling shellchange_debug in Opus would have no effect whatsoever on Windows Explorer (except maybe slight changes in the timing of things, which should make no difference to either program).

For it to stop working in Explorer as well suggests a problem with what the drive is doing, and not a problem in Opus or Explorer.

You didn't say which file you were applying the change to, but I assume it's this one, from the last two logs:

\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951\CSR\L1NGAU2.csr

It's potentially odd (at least not knowing the filesystem's semantics), that the drive also sends an event for:

\CMNP\Produktions-ChangeMan\C07A\Packages\C07A001951!\L1NGAU2.csr