File list not updating for Hitachi NAS

Help & Support
1

This issue only appears on mapped drives on a Hitachi NAS.

The operation being peformed in another process is to generate a html file from a markdown file New Markdown File.md --> New Markdown File.html

I have two Folder Tabs open to the same physical location containing New Markdown File.md

  • Folder Tab path: H:\_Dopus
  • Folder Tab path: \\CORP\users\MKT\Me\_Dopus 
>net use h:
Local name        h:
Remote name       \\CORP\users\MKT\Me
Resource type     Disk
  • In the Folder Tab path: H:\_Dopus no changes are displayed in the window.
  • In the Folder Tab path: \\CORP\users\MKT\Me\_Dopus changes are displayed in the window.

debugview

00000043	3:05:59 PM	[8652] [15416] dopus: Notify 0000000007E08830 Returned 0 bytes, error 0	
00000044	3:05:59 PM	[8652] [15416] dopus: Notify 00000000077283D0 Returned 0 bytes, error 0	
00000045	3:05:59 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\Me\_Dopus
00000046	3:05:59 PM	[8652] [15416] dopus: Notify 00000000077283D0 Returned 0 bytes, error 0	
00000047	3:05:59 PM	[8652] [15416] dopus: Notify 0000000007E08830 Returned 0 bytes, error 0	
00000048	3:05:59 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\Me\_Dopus
00000049	3:05:59 PM	[8652] [15416] dopus: Notify 0000000007E08830 Returned 0 bytes, error 0	
00000050	3:05:59 PM	[8652] [15416] dopus: Notify 00000000077283D0 Returned 0 bytes, error 0	
00000051	3:05:59 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\Me\_Dopus
00000052	3:05:59 PM	[8652] [15416] dopus: Notify 0000000007E08830 Returned 0 bytes, error 0	
00000053	3:05:59 PM	[8652] [15416] dopus: Notify 00000000077283D0 Returned 0 bytes, error 0	
00000054	3:05:59 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\Me\_Dopus
00000055	3:05:59 PM	[8652] [15416] dopus: Notify 0000000007E08830 Returned 0 bytes, error 0	
00000056	3:05:59 PM	[8652] [15416] dopus: Notify 00000000077283D0 Returned 0 bytes, error 0	
00000057	3:05:59 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\Me\_Dopus
00000058	3:06:00 PM	[8652] [15416] dopus: Notify 0000000007670C10 Returned 294 bytes, error 0
2

  • Does File Explorer show the changes OK for both methods of accessing the folder?

  • From the debug log above, I am surprised it is working at all as 153 is not a valid change number. Valid numbers are 1 through 5. That may mean the device is generating change notifications incorrectly.

  • I did a quick test here with a similar setup and Windows machines at both ends, and the changes were picked up for both the drive letter and the UNC path, in both Opus and Explorer.

3

The changes were detected in Windows File Explorer using the UNC path and Drive path.
The changes were not detected in the DOpus Drive path Folder Tab.

DebugView output

00000421	12:05:42 PM	[8652] [15416] dopus: Notify 0000000007D8F950 Returned 232 bytes, error 0	
00000422	12:05:43 PM	[8652] [15416] dopus: Notify 0000000008F2C6E0 Returned 0 bytes, error 0	
00000423	12:05:43 PM	[8652] [15416] dopus: Notify 00000000048FD9B0 Returned 0 bytes, error 0	
00000424	12:05:43 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\me\_On-call	
00000425	12:05:43 PM	[8652] [15416] dopus: Notify 0000000008F2C6E0 Returned 0 bytes, error 0	
00000426	12:05:43 PM	[8652] [15416] dopus: Notify 00000000048FD9B0 Returned 0 bytes, error 0	
00000427	12:05:43 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\me\_On-call	
00000428	12:05:43 PM	[8652] [15416] dopus: Notify 0000000008F2C6E0 Returned 0 bytes, error 0	
00000429	12:05:43 PM	[8652] [15416] dopus: Notify 00000000048FD9B0 Returned 0 bytes, error 0	
00000430	12:05:43 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\me\_On-call	
00000431	12:05:43 PM	[8652] [15416] dopus: Notify 0000000008F2C6E0 Returned 0 bytes, error 0	
00000432	12:05:43 PM	[8652] [15416] dopus: Notify 00000000048FD9B0 Returned 0 bytes, error 0	
00000433	12:05:43 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\me\_On-call	
00000434	12:05:43 PM	[8652] [15416] dopus: Notify 0000000008F2C6E0 Returned 0 bytes, error 0	
00000435	12:05:43 PM	[8652] [15416] dopus: Notify 00000000048FD9B0 Returned 0 bytes, error 0	
00000436	12:05:43 PM	[8652] [24420] dopus: Change 153 on \\CORP\users\MKT\me\_On-call	
00000437	12:05:43 PM	[8652] [15416] dopus: ShellChange: 00000000086A1780, 3	
00000438	12:05:43 PM	[8652] [15416] dopus: ShellChange: dwEvent = 2000	
00000439	12:05:43 PM	[8652] [15416] dopus: ShellChange: update item = H:\_On-call\New Markdown File.html	
00000440	12:05:43 PM	[8652] [15416] dopus: Notify 0000000007D8F950 Returned 160 bytes, error 0
4

This looks like a limitation of Hitachi NAS:

From Hitachi's forums, assuming I have found the correct product, a Feb 2017 thread with a July 2017 response here: https://community.hds.com/thread/11465-filsystemwatcher-dont-work-on-hnas

FileSystemWatcher doesn't work on HNAS

Hitachi NAS has only limited support for this feature of the SMB Protocol.

Our current implementation of change notification, does not inform clients what has changed, merely that a directory has changed. It is then up to the client to determine what has changed by enumerating the directory

Also a thread from 2013 saying it didn't support change notification at all at the time. https://community.hds.com/thread/3591

Whatever it is doing, sending change event 153 is completely invalid, as the valid events are only 1-5 as follows:

  1. FILE_ACTION_ADDED
  2. FILE_ACTION_REMOVED
  3. FILE_ACTION_MODIFIED
  4. FILE_ACTION_RENAMED_OLD_NAME
  5. FILE_ACTION_RENAMED_NEW_NAME

It's also generating events for the folder, not the file being modified, which ties in with the 2017 thread quoted above. The thing is, there is no documented way to even ask for the whole folder to be re-read like they are describing, at least that I know of and via the API in question.

It is possible that Explorer interprets an invalid event value as "I have no idea what this device is telling me, so I'll re-read the entire folder", but that is both undocumented and will have terrible performance, and is not needed for any other device we know of, so it's not something we are going to do.

It's interesting that there is a shell change event for the file in the second log. It's possible that Explorer itself is generating that after re-reading the folder, but only if it happens to be looking at the folder, in an attempt to tell other programs about the change it noticed. (Explorer does this in a few other cases to help with badly written devices, e.g. optical drives which do not report eject/insert correctly.)

At the end of the day, this looks like Hitachi's NAS solution is unfinished and doing something illegal according to the API docs. If so, you'll see similar problems in other programs which monitor folders (e.g. FileSystemWatcher, as mentioned in the quoted thread). It does not look like something we can fix, at least in a reasonable way, and on the flipside it absolutely is something that a NAS should do properly in 2017, so in my opinion you should complain to Hitachi about this.

5

Thanks for the excellent follow up. I had searched the Hitachi website but didn't find anything relevant.
I will follow up with my IT infrastructure support.