Bug 13997 - Windows client error handling for failing write on macOS stream AFP_AfpInfo depends on Directory Leases
Summary: Windows client error handling for failing write on macOS stream AFP_AfpInfo d...
Status: ASSIGNED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Ralph Böhme
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-17 09:15 UTC by Ralph Böhme
Modified: 2019-07-02 14:17 UTC (History)
2 users (show)

See Also:


Attachments
Fake Directory Leases (4.09 KB, patch)
2019-06-17 09:15 UTC, Ralph Böhme
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2019-06-17 09:15:42 UTC
Created attachment 15251 [details]
Fake Directory Leases

macOS SMB server and Samba with fruit do a validity check on the data written to the AFP_AfpInfo stream.

Invalid data, eg where the the first three bytes do not contain the magic string "AFP" cause a write on this stream to fail with NT_STATUS_INVALID_PARAMETER.

macOS SMB server also support Directory Leases since 10.13. When the Windows client receives the error for the write from a macOS server, the Windows Explorer hides the error from the user *if the server supports Directory Leases*.

Steps to reproduce:

* Windows client connected to macOS SMB 10.13 (or newer)

* file on the client with an associated stream "AFP_AfpInfo" with invalid data

* in Windows Explorer copy file to server

* copy succeeds, no user visible error

* disconnect Windows client from macOS SMB server, connect to Samba (with fruit+streams_xattr)

* copy file to server

* copy fails

Adding a fake Directory Leases implementation lets the copy pass.
Comment 1 Nathan Palmer 2019-07-02 11:01:02 UTC
We have done some testing with this patch and noticed that Windows Clients connected to the same share do not receive folder/file updates from another client.

1. Client A connects to share X.
2. Client B connects to share X.
3. Client A creates a new file.
4. Client B does not detect the new file is there for ~10 minutes or disconnect/reconnect.
5. Client B deletes the file.
6. Client A does not detect the file is deleted until attempting to open the file or ~10 minutes.

I would strongly caution against using this patch at this time.
Comment 2 Ralph Böhme 2019-07-02 11:03:31 UTC
(In reply to Nathan Palmer from comment #1)
Heavens, the patch description clearly says "Fake directory leases" and the patch subject contains "HACK", so yes, you're NOT supposed to run this patch in production. :)
Comment 3 Nathan Palmer 2019-07-02 14:17:39 UTC
Just making it explicitly obvious with a test scenario to showcase :)

We are currently testing an in house patch that may resolve this problem. Once we complete testing we will update and let you know.