## Problem Implement an in-memory file store that grows through four levels: file operations, search, user capacity, and compression. Process a sequence of operations and return one result for each operation. ### Function Contract Implement `runFileStore(operations)` with these operations: - `["add", name, size]`: add an admin-owned file and return `true`; return `false` if `name` exists. - `["copy", source, destination]`: copy the file with the same size and owner; return `true` on success. Return `false` if the source is missing, the destination exists, or the owner's remaining capacity is insufficient. Admin has unlimited capacity. - `["find", prefix, suffix]`: return matching files as `name(size)`, sorted by size descending and then name ascending. - `["add_user", userId, capacity]`: add a user and return `true`, or `false` if the ID exists. The reserved ID `admin` already exists. - `["add_by", userId, name, size]`: add a file owned by the user and return remaining capacity; return `null` if the user is missing, the name exists, or capacity is insufficient. - `["set_capacity", userId, capacity]`: update capacity. If current usage exceeds it, delete that user's largest files first, breaking size ties by lexicographically greatest name. Return the number deleted, or `null` for a missing user or `admin`. - `["compress", userId, name]`: for a file owned by that user, replace it with `name + ".COMPRESSED"` at half its size and return the new remaining capacity. Return `null` if ownership fails, the source is missing, or the destination exists. - `["decompress", userId, compressedName]`: remove the final `.COMPRESSED`, double the size, and return remaining capacity. Return `null` if the name or owner is invalid, the destination exists, or capacity is insufficient. ### Constraints & Assumptions - At most `100,000` operations are supplied. - Names and user IDs are nonempty strings. - `1 <= size, capacity <= 10^12`. - Files eligible for compression have even size, so halving is exact. - File names are global; directories and physical disk I/O are out of scope. ### Clarifying Questions to Ask - Does a copied file retain its original owner? Yes, and its size counts against that owner's capacity. - Can admin files exceed a capacity? Yes; admin is unlimited. - Does compression change ownership? No. - Must lower-level operations be rewritten after users appear? Their shared helpers should enforce the new owner and capacity invariants. ```hint Centralize mutations Keep global files by name and users by ID. Route every creation and deletion through helpers that update both the file map and the owner's consumed capacity. ``` ```hint Validate before replacing Compression and decompression should check destination collision and final capacity before removing the source file. ``` ### Example ```text operations = [ ["add_user", "u1", 100], ["add_by", "u1", "report", 60], ["compress", "u1", "report"], ["copy", "report.COMPRESSED", "backup.COMPRESSED"], ["find", "", ".COMPRESSED"] ] output = [true, 40, 70, true, ["backup.COMPRESSED(30)", "report.COMPRESSED(30)"]] ``` ### Evaluation Focus - Maintains global name uniqueness and owner usage consistently. - Applies capacity checks to copies and decompression. - Makes compression/decompression atomic on failure. - Implements deterministic search and capacity-shrink deletion order. - Reuses lower-level behavior instead of duplicating divergent logic. ### Extensions to Discuss 1. Which indexes would speed up prefix-and-suffix search? 2. How would concurrent operations acquire locks without deadlocking? 3. How would you add directories while preserving global ownership accounting?