Scenario:

1. Setup
- Create a test file - payload.txt - in any storage accessible via WebDAV
- Map a drive on Machine A via WebDAV

2. Machine A
- Start clock
- Compose a GroupWise email
- Attach payload.txt

3. Machine B
- Edit payload.txt and ensure it resyncs to WebDAV

4. Machine A
- While clock < 60 seconds send email
- 60 second limit is defined by HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxDAV\Parameters\FileNotFoundCacheLifeTimeInSec

5. On arrival, the unedited version of payload.txt from Step 2 will be received

Compare this to other email clients such as ThunderBird, which will send the current (per Step 3) version.

The logic appears to be:

- When GroupWise attaches the file, it pulls that file down immediately
# It uses the cached copy of the file in C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV
# It will update the attached copy only if FileNotFoundCacheLifeTimeInSec has passed and the cache is updated

- When Thunderbird attaches the file, it [apparently] attaches a pointer and only pulls the source file down when the email is actually sent

Although this is a corner case and there is less than a minute to fall foul of this anomaly, it *is* still possible to end up sending the wrong version of the file (and real-world users have managed to do this).

Is it possible to fix this so that GroupWise Client requests the source file just as it is being sent (rather than the cached version in Tfs_DAV), as Thunderbird appears to do?

MRFE / MG / 101050052001 / 1024731

by: Marcus G. | over a year ago | Windows Client