Alas, a Mac client wouldn't do this, but what can you do? Currently when the client sends a AFP_AfpInfo stream where the contained FinderInfo blob is all 0, vfs_fruit will somewhat hackish delete the stream from the backing store. This causes subsequent operations on the same filehandle to fail for certain operations, also depending on the setting of fruit:metadata. The correct implementation of the stream removal would be setting delete-on-close on the filehandle, while at the same time checking in delete-on-close is set in the stream-listing function. Have patch, need bugnumber.
Created attachment 13910 [details] Patch for 4.7 cherry-picked from master
Created attachment 13911 [details] Patch for 4.6 backported from master
Re-assigning to Karolin for inclusion in 4.7.next, 4.6.next.
Pushed to autobuild-v4-{7,6}-test.
(In reply to Karolin Seeger from comment #4) Pushed to both branches. Closing out bug report. Thanks!