mirror of
https://github.com/HeyPuter/puter.git
synced 2026-09-10 23:36:06 +00:00
Juan Castro
ee2b5adcf9
A recipient's client keeps its cache fresh from fs events pushed over their socket, and ShareService fans those out to holders — but only for write, move and delete. A new entry emits fs.create.<flavor>, not fs.write.file, and an in-place rename emits fs.rename; neither had a listener, so a recipient watching a shared folder never learned that a file appeared in it or was renamed. Part of why: those keys and outer.gui.item.renamed were missing from the typed event map, so a listener for them did not compile. Delivering the event is only half of it. Paths were masked against the entry itself, so item.added named a parent no cached listing was keyed on, and the payload carried no dirpath, which is how the desktop finds the container to render into — the event would have arrived and changed nothing. Paths are now masked at the share the holder reached the entry through, which is the address their own reads returned, and from_path on a move and old_path on a rename travel the same way (dropped when the move started outside the share, self-masked when the share is on the entry itself, where the root already carries the new path). Creates fire per entry, so an upload would have cost one share lookup per file; they are coalesced by parent folder the way subtree deletes already are. Measured on a 25-file burst into one folder: 25 lookups before, 1 after. A holder with a share on both a folder and something inside it is told once, by the nearer of the two.