View Issue Details

IDProjectCategoryView StatusLast Update
000697010000-020: File TransferSpecpublic2021-11-03 21:47
ReporterZbynek Zahradnik Assigned ToJeff Harding  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version1.05.01 RC1 
Summary0006970: Missing reliable way to reflect file changes on the client side
Description

What I want to achieve is basically a reflection of a status of the file system inside the OPC UA Server, on a client side - a "cached" copy of what files and directories the server has. I believe this is a fairly common scenario (for efficiency reasons, offline work etc.). But I do not think it is achievable with 1.04 spec, because the client has no way to tell whether the file contents has changed.

In my scenario it is OK to be able to "sync" files data only when the file is in closed state (it is not necessary, and even not desirable, to be informed about every change).

What does not work:

  • You cannot take one of the existing FileType properties such as "Size" and detect changes, because the size does not have to change even if the data had changed.
  • You cannot take timestamps of any properties defined on FileType (at least not with the implementations I have tested with) and detect the changes; the timestamps can remain the same even if the file data has changed.
  • You cannot subscribe to the OpenCount property to detect that somebody is manipulating the file, for two reasons: a) The server can change file contents "from inside", without opening the file, and b) this does not allow to detect a change while the server was down and/or client was disconnected for any reason.

The proposed solution is to add some kind of version counter on the FileType that the server would have to increment whenever the file data have changed. A "false positive" (incrementing when not needed) would be in principle OK (just leading to an inefficiency in client-side caching). Ideally this would be made mandatory so that server implementors actually bother implementing it; but if not doable, it can stay optional.

An alternative solution would be a something like LastModifiedTime property.

For reliably, it is absolutely necessary that if there is any chance that the file contents have changed during server restart, the server shall increment the version counter or update the lastModifiedTime.

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0007384 closedRandy Armstrong NodeSets, XSDs and Generated Code Missing reliable way to reflect file changes on the client side 

Activities

Zbynek Zahradnik

2021-06-15 15:40

developer   ~0014565

Last edited: 2021-06-15 15:40

Agreed on the meeting to add optional LastModifiedTime property to the FileType.

Add following text:
The property should be updated with the time the file has been modified, whenever the server detects that the file has changed.

Jeff Harding

2021-09-22 18:04

developer   ~0014927

Agreed to add to 1.05 release

Jeff Harding

2021-09-22 18:31

developer   ~0014931

Added the property with the following definition:

The optional LastModifiedTime Property indicates the time the file was last modified. The Property shall be updated whenever the Server detects that the file has changed.

Jim Luth

2021-10-12 15:56

administrator   ~0015164

Need to rollback from 1.05.0 and make the change in 1.05.01

Jeff Harding

2021-10-12 16:13

developer   ~0015165

1.05.0 changes rolled back.

Jeff Harding

2021-10-12 16:14

developer   ~0015166

Fixed in 1.05.1 version

Jim Luth

2021-11-03 21:47

administrator   ~0015262

Agreed to changes prior meeting.

Issue History

Date Modified Username Field Change
2021-05-28 06:44 Zbynek Zahradnik New Issue
2021-06-15 15:40 Zbynek Zahradnik Note Added: 0014565
2021-06-15 15:40 Zbynek Zahradnik Note Edited: 0014565
2021-06-15 15:41 Karl Deiretsbacher Project 10000-005: Information Model => 10000-020: File Transfer
2021-06-15 15:42 Karl Deiretsbacher Assigned To => Jeff Harding
2021-06-15 15:42 Karl Deiretsbacher Status new => assigned
2021-06-15 15:42 Karl Deiretsbacher Target Version => 1.05
2021-09-22 18:04 Jeff Harding Note Added: 0014927
2021-09-22 18:31 Jeff Harding Status assigned => resolved
2021-09-22 18:31 Jeff Harding Resolution open => fixed
2021-09-22 18:31 Jeff Harding Fixed in Version => 1.05.00
2021-09-22 18:31 Jeff Harding Note Added: 0014931
2021-10-12 15:56 Jim Luth Status resolved => feedback
2021-10-12 15:56 Jim Luth Resolution fixed => reopened
2021-10-12 15:56 Jim Luth Note Added: 0015164
2021-10-12 15:56 Jim Luth Status feedback => assigned
2021-10-12 16:13 Jeff Harding Note Added: 0015165
2021-10-12 16:14 Jeff Harding Status assigned => resolved
2021-10-12 16:14 Jeff Harding Resolution reopened => fixed
2021-10-12 16:14 Jeff Harding Fixed in Version 1.05.00 => 1.05
2021-10-12 16:14 Jeff Harding Note Added: 0015166
2021-11-03 21:42 Jim Luth Issue cloned: 0007384
2021-11-03 21:42 Jim Luth Relationship added related to 0007384
2021-11-03 21:47 Jim Luth Status resolved => closed
2021-11-03 21:47 Jim Luth Fixed in Version => 1.05.01 RC1
2021-11-03 21:47 Jim Luth Note Added: 0015262