ShareManager.receive uses node in self.share_list[from_username], which relies on Node.__eq__ comparing name/is_folder/file_obj. Two different files named "report.pdf" from the same sender with different CIDs will be treated as identical because Node.__eq__ doesn't actually check child structure on folders (children dict isn't compared). A stable per-node UUID fixes multiple bugs at once.
Current state:
Node.__eq__ in node.py compares (name, is_folder, file_obj); children and subtree are not part of equality. File.__eq__ compares all four fields including creation_date, so it's narrower than expected.
Proposed implementation:
- Add
node.id = str(uuid.uuid4()) on creation, persisted in JSON.
ShareManager.receive dedups by id.
ShareManager.delete takes an id instead of comparing by (name, is_folder).
- Migration: on load, backfill missing IDs.
Files likely affected:
backend/node.py
backend/share_manager.py
backend/delete_service.py
- Tests.
Acceptance criteria:
- Two distinct files with the same name from the same sender are both kept in the share list.
- Deleting one removes exactly one.
- Existing serialized trees continue to load.
ShareManager.receiveusesnode in self.share_list[from_username], which relies onNode.__eq__comparing name/is_folder/file_obj. Two different files named "report.pdf" from the same sender with different CIDs will be treated as identical becauseNode.__eq__doesn't actually check child structure on folders (children dict isn't compared). A stable per-node UUID fixes multiple bugs at once.Current state:
Node.__eq__innode.pycompares(name, is_folder, file_obj); children and subtree are not part of equality.File.__eq__compares all four fields includingcreation_date, so it's narrower than expected.Proposed implementation:
node.id = str(uuid.uuid4())on creation, persisted in JSON.ShareManager.receivededups byid.ShareManager.deletetakes anidinstead of comparing by(name, is_folder).Files likely affected:
backend/node.pybackend/share_manager.pybackend/delete_service.pyAcceptance criteria: