streams_depot/streams_xattr VFS modules don't handle write/pwrite requests, so they are redirected as default operations via file-handle to streams files. In such way modification time of the base file is NOT updated on stream modification. The same behavior should be implemented for access time. P.S. Still we cannot update modification/access time on each write/pwrite call due performance penalty. As a solution we can update times on the very first write and on fsp close (if was modified), but we must add additional field to fsp to track those events.
Hmmm. This is an interesting one. In order to track it the best thing would be to have a torture test to determine the exact Windows semantics we need to emulate. How did you do the testing to determine this issue ? Jeremy.
Actually I've detected this issue basing on code investigation. You see, we have own implementation of streams VFS module (we supported alternate streams before samba implemented this feature by streams_xxx), and our code takes this feature into account.
Ok, but what we need to do in order to do this properly is to add a torture test so we can investigate exactly how Windows behaves in this matter. I suggest adding a second delayed write request test (in source3/torture/torture.c) that updates a non-default stream. Once we know how it's *supposed* to behave, then we can add the correct logic into smbd. Jeremy.
The issue of course is when you say "our code takes this feature into account" - what were the design criteria for your implementation of this feature ? How did you know when you'd got the feature correct ? If you already have a test, this will help us a lot. Jeremy.
(In reply to comment #4) > How did you know when you'd got the feature correct ? If you already have a test, > this will help us a lot. Yes, you are right - behavior of the Windows itself is the standard here. For sure we had run some tests, but AFAIK they were manual. Now I can propose two test-plans to check this: Test#1 (trivial mtime update): 1. Create a_file.txt: echo file > a_file.txt 2. Get modification time of the file. 2. Wait for a second: sleep 1 (or set STAT info to some time in the past) 3. Attach a stream with some data to the file: echo stream > a_file.txt:stream 4. Get new mtime of the base file (a_file.txt) 5. Compare two creation times: they must be different Test#2 (mtime update during write progress) 1. Create a_file.txt: echo file > a_file.txt 2. Create or get the large file somewhere: dd if=/dev/zero of=large.bin bs=1K count=1000 3. Start writing large file to the stream: more large.bin > a_file.txt:stream 4. Watch the changes of mtime for the base file: AFAIS mtime of the base must be updated on the stream close (when operation is finished). This is manual test, but it can be adapted for samba torture as following: 1. Create a_file.txt 2. Get mtime of the file. 3. Sleep 1 4. Open a new stream for this file (keeping it opened): a_file.txt:stream 5. Check modtime of the base 6. Sleep 1 7. Write some data to the stream 8. Check modtime of the base 9. [repeat 6-8 few times] 10. Sleep 1 10. Close the stream handle 11. Check modtime of the base By this test we can discover when the mtime is actually updated: on the stream creation / on some write (the first?) / on close.