Files

Files (filesv2) is a separate application for personal and group storage. It presents Cloud and FreeIPA directories in one file browser. Administrators manage directory creation, assignments, and archives separately from everyday browsing. File transfers use short-lived Filegate leases.

The details panel shows five text lines or CSV data rows, followed by the number of remaining lines. Open the expanded preview to read more; CSV tables paginate through 200 rows at a time. Existing preview size and column limits still apply.

A readable README.md in the current folder appears below the view controls and above list and grid content, without a frame, with compact headings, tighter paragraph spacing, and a fixed preview height of 20vh. The preview reserves this space while loading to keep the file listing in place. Tree view hides this preview and reserves no space; the README remains accessible as a normal file. Folders without a readable README reserve no space. File-name matching ignores case and is independent of the visible page and filters. If several variants exist, README.md takes precedence, then readme.md, then the remaining names in lexical order. Detection scans at most 10,000 immediate entries and omits the README if that scan is incomplete. The file remains in the normal listing; when the description overflows, a fade and Show all action appear at the bottom. The action opens its full preview with normal-sized headings.

Open /app/filesv2 to start at All storage: one tile per storage location you can reach, with its name, kind, and source, followed by your recently opened files. A storage location that is not usable stays a tile and shows its status. Recent loads on its own below the tiles; if it fails, only that section shows the error and Try again, and the tiles stay usable. Open a tile to work in that location; you create and upload there. The overview offers no create action, and a file dropped on it is refused rather than uploaded or opened by the browser. If you can reach exactly one storage location, Files opens directly inside it and shows no overview. The overview is navigation only: it lists the same storage locations as cld filesv2 ls without a folder, and the service checks access on every request as before. Only the plain address changed: links with ?base=…, /ref/…, trash and share links, and CLI addresses such as me:/… behave as before. Your home directory is listed as Personal with its technical name as secondary text; group directories carry the group's name. Breadcrumbs, the details panel, Recent, Favorites, and your share list use the same labels, while the API and CLI keep the technical name. Only storage areas that apply to your account provider are listed or reported: a local account never sees FreeIPA storage and a FreeIPA account never sees local Cloud storage. With more than one storage location, the sidebar and the phone navigation menu start with All storage, followed by the same storage choices. Switching storage, opening folders, and changing pages update the workspace without reloading the whole page. Navigation and pagination stay in the URL, so reloads and browser Back and Forward preserve your location. Missing or inaccessible storage appears with its status rather than as an empty directory.

Browse, select, and preview

The sidebar has Recent, Favorites, Shares, and Activity above the folder trees. Its footer offers Search, the global Cloud search restricted to files. After every navigation exactly the current path is expanded; the tree holds only storage locations and folders. The list is a flat striped list; folders open on click (the opened folder's icon becomes a spinner, a leading Parent folder row names the folder above and goes up; the header shows the current folder's name alone, with no back link at any depth, and Backspace in the list or Alt+↑ go up too), files open the details panel, and every row ends with an info button. With more than one storage location, the root folder of each one starts with an All storage row that leads back to the overview; Backspace and Alt+↑ follow it too, also in Tree view and search results, which hide the row. Items cannot be moved onto that row; files dropped on it from your computer upload into the storage root, as anywhere else in the list. The root folder of each storage location ends with a Trash row that opens its trash. List, Grid, and Tree views and the grid tile size are remembered per storage location in a cookie. Tree shows the storage from its root with the current folder highlighted; clicking a folder name makes it current, clicking its icon expands or collapses it. Moving between folders preserves loaded tree branches. While ancestors load, or if their request fails, the current folder remains visible; a failed tree request offers a retry. Sorting, filtering, or changing the storage location rebuilds the tree with the new context. Select next to the entry count switches on checkboxes in every view. Thumbnails are requested with bounded concurrency and retried, because Filegate rejects parallel renders beyond its capacity. Storage, folder, page, single selection, and the search with its filters stay in the URL. The Sort and filter icon button beside search groups Sort by, Order, and Type in one menu. Sort by name, modification date, or size; filter all entries, files, or folders. The default is name ascending, with folders before files. Group folders is on by default; turn it off to sort files and folders together. Grouping and sorting are remembered per storage location; reset restores name ascending, all types, and grouping. The Parent folder row stays above the entries regardless of grouping, sorting, or type filter and cannot be selected. Sorting and filtering apply before pagination. With grouping on, all folder pages come before file pages; each group uses the selected order. These options stay in the URL. An expired or invalidated cursor restarts at the first page with a notice. Entries can be dragged onto folders or the Parent folder row to move them (resting on a folder opens or expands it), and marked as favorites. Recent and Favorites open compact sidebar menus on desktop and dialogs from mobile navigation. Recent shows the latest entries with relative times; favorites are alphabetical. Entries are checked against current access and file existence when the menu opens. The outline star beside Preview and Download in the details panel turns gold for a favorite; hover or keyboard focus shows an X for removal. Tapping the selected star removes the favorite too. The current page is polled while the tab is visible so changes by others appear without a reload. PDF and office files use file-type icons in lists and grids. Images retain direct Filegate thumbnails; PDF contents remain viewable in the details panel.

Search always covers the subtree below the current folder and uses Filegate 7.1 search. By default it matches names and folder names below the folder (in=path), tolerates typos and loose abbreviations (match=fuzzy), and ranks the best matches first (sort=relevance). Matching ignores case, accents and separators and accepts up to eight query words in any order. Each hit shows its name and its folder below the searched one, with the matched characters marked by MatchText; the API returns them as highlight, Unicode code point ranges into the hit's path below the searched folder. The result count shows total when it is exact: Filegate collected the whole selection, the area is Cloud storage, the search covers all levels, and hits in the base's trash are subtracted. A query word that could match the trash folder's own name leaves the total unknown, so a count never reveals a hidden trashed entry. Otherwise the count says how many hits the page holds. Relevance keeps Filegate's best hits (1,000 by default); truncated: true then says that the pages end before total.

Type, Size, and Modified chips filter by extension groups, byte ranges, and rolling time windows (24 hours to 12 months, counted from the current full hour); with a filter or the Folders type, a search needs no query. Sort and filter switches between best match, name, date, and size, and to exact names only (match=exact&in=name). Query, scope, filters, match mode, and order stay in the URL, so reload, back, and shared links show the same search; folder sort preferences do not apply to searches. While a search runs, the toolbar keeps its size and the results area shows placeholder rows of the list's geometry. Filegate gives every search a 10-second budget: an exceeded budget shows This search takes too long with exact-name search (indexed storage) and the way back to the folder, never a partial result. Other failures keep the search field and filters and offer a retry. Cloud retries a busy root (429 search_busy) twice after one second, restarts a first page whose observation changed once, and answers a stale continuation with cursor_invalid, which returns the browser to the first page with a notice. Files also answers the universal search under the file tag through the filesv2.entry resource type with the same defaults, searching at most two storage bases at a time and taking each base's best hits in turn. Each entry's Cloud reference can be copied from the details panel.

Selections act through one Actions menu: direct download for one file, a signed Filegate ZIP for several entries or folders, move into a new folder, move, copy, public share, trash. Moves never leave a base. Copies can cross bases including Cloud-to-FreeIPA and FreeIPA-to-Cloud copies. Filegate reads the source under its authorized execution identity and publishes under the destination identity. Cloud files belong to the service account; FreeIPA copies receive the authorized Unix ownership and modes. Different execution contexts require distinct Filegate roots. Deleting moves entries into the reserved trash folder with a restorable record; only administrators empty it. Renaming, duplicating and moving reuse Filegate transfers.

The details panel shows a compact preview, actions, facts, versions, and history. On phones, the preview is hidden and the version count opens the versions list. Folder details show the number of loaded items; “at least” means more items may remain. If the count cannot load, Try again retries it.

Where storage keeps versions, the count includes the current file and retained versions. Each saved version offers a comment, download, restore in place, and restore as a new file. If refreshing the list fails, the last loaded versions remain visible with a retry; their actions stay disabled until the list loads. A person's name beside the current modification appears only when the recorded change matches the file's current revision. A version comment's author identifies the person who wrote the comment, not the content's author. Restoring as a new file uses Filegate's historical-copy operation and leaves the original file, modification time, identity, and history unchanged. Permanent version deletion is available only through the administrator file browser and CLI.

Uploads report progress in one toast and resolve name conflicts once per batch (replace existing or upload only new). Uploads, folder uploads and new files open a Filegate upload session per file: Cloud authorizes the target, the browser streams segments to the session lease and renews it through Cloud, and Cloud commits after re-checking the target. Temporary failures (no connection, no answer, a busy server, rate limits, or other server errors) keep the session and its upload ID. Retrying the same unchanged file resumes from acknowledged segments. Cloud records the bound destination, write options, and execution identity before issuing the session. A lost commit answer keeps the ID so a retry can recover the retained result. Final failures, such as name or write conflicts, a closed or unknown session, a changed upload, or insufficient space, discard the failed upload and its ID. Files asks again whether to replace after a name or write conflict; an unknown upload record starts fresh on retry. Discarding an open, unpublished session requests an abort and removes its ID only after confirmation. An explicit cancel during an attempt also requests an abort before commit. Cancelling a wait stops retries and retains the session and key. Once commit has been sent, a lost or temporary answer keeps the ID and never triggers an abort, including cancellation. Only a definite name or write conflict at commit can abort that unpublished session. Filegate retains terminal receipts for seven days. Browser upload IDs expire locally 24 hours plus seven days after their last attempt and are pruned at the next upload.

The working row in the upload panel shows the transferred bytes on its second line. After transfer, a commit still pending after one second shows Finishing… on that line; waits replace it there too, so the row never moves. Filegate commit calls have up to ten minutes; the Cloud request allows 240 s, and browser and CLI commit deadlines allow 255 s so Cloud or the gateway can answer first. A commit that outlasts the request budget is recovered by the automatic retry with the same upload ID. While that commit still holds the Filegate root (filegate#6), Filegate calls on the root can reach their 10 s deadline; Files answers such a deadline with unavailable (503), which upload clients retry like a busy file server. Filegate needs free space for a second copy while committing (filegate#9).

Every transfer request has a deadline sized for the slowest supported uplink of about 0.5 Mbit/s (64 KiB/s). These per-request deadlines remain the stall detector; the queue adds no inactivity timer. After automatic retries are exhausted, the file fails with its reason and the batch continues with the next file. Browser failures distinguish “No response from the server” for Cloud requests from “No response from the file server” for transfers. HTTP 408, 502, 503, and 504 report a busy file server; HTTP 429 reports too many uploads in a short time.

The workspace and public inbox use the same automatic wait policy. Every attempt reopens the same session with the same idempotency key and resumes from acknowledged segments:

• When the browser is offline or Cloud cannot be reached, a network failure pauses the current file; pending files stay pending. When the browser reports a connection, probes wait 2 s, double their interval, and stop growing at 30 s. An online event or returning to a visible tab while online starts a probe immediately. No probe timer runs while the browser reports offline. There is no probe count limit; Cancel and the Filegate session lifetime of 24 hours bound the wait. After expiry, the session's start response is final.
• A stalled or busy server gets five retries after 2, 5, 15, 30, and 60 s, or a larger Retry-After. The row shows the reason while waiting and “Trying again” during subsequent attempts until the file finishes. The network wait ends when Cloud answers or progress arrives. A network failure after Cloud answered (the file server cannot be reached) counts toward the five retries.
• HTTP 429 with Retry-After waits as requested without spending those five retries, at most ten times per file. Without Retry-After, it counts as busy. Retry-After above five minutes is not waited out automatically.
• Other server errors and final errors are not retried automatically. A manual Try again starts a fresh retry budget. A successful probe or attempt does not reset the retry or rate-limit budget within a run.

The Filegate SDK's short request retries run inside each attempt; the queue is the only additional retry layer. Cancel or leaving the workspace ends a wait immediately. The panel announces loss and return of the connection once per transition, rather than once per failed probe.

Create folders

New folder accepts nested paths such as A/B/C and sibling names in the last segment, such as Testdaten/Test1, Test2, Test3. A typed comma offers the choice between separator and part of the name. The preview marks existing folders and invalid names before creation. Existing folders are reused, and one submission includes at most 100 folders, counting every folder in between. That is the bound every Files batch (move, copy, trash) already uses; it also bounds the depth, together with the 4096-character path limit. Each name is limited to 255 UTF-8 bytes; accented letters and emoji use more than one byte. A conflict or denied permission blocks creation and is shown next to the affected folder. While creation runs, the dialog cannot be dismissed.

POST /api/filesv2/bases/:baseId/directories/batch accepts {paths: string[], dryRun: boolean}; dryRun defaults to false. Paths are base-relative, at most 4096 characters each, and the list contains 1–100 paths. Each segment is limited to 255 UTF-8 bytes, including children of planned folders. All paths are validated before any creation. Duplicates are removed and parents are processed before children, preserving input order at equal depth. The endpoint creates exactly the supplied paths; it does not add ancestors. Existing folders require read access and are reused without write access to their parent. Creating a missing folder requires a readable, writable parent and uses the same ownership as single-folder creation.

The response is {base, results} with one {path, state, entry?, error?, message?} per unique path. States are existing, created, planned, failed, or skipped. A real run stops after the first failure; earlier creations remain and later paths are skipped. A dry run creates nothing and checks independent paths even after a failure. Descendants of planned folders are planned; descendants of failed or skipped folders are skipped. Errors keep stable codes, with localized messages on failed items. A dry run reserves nothing; access or storage may change before creation. create_forbidden means the parent can be read but does not allow folder creation. Filegate failures use the same error codes as single-folder creation.

cld filesv2 mkdir [-p] <folder>... accepts several folders in one area. With -p, one batch includes all ancestors and reuses existing folders; put --parents uses the same endpoint. Without -p, folders are created individually in argument order and existing names fail. Both modes report created and unattempted folders on failure. Commas stay literal in CLI names; pass siblings as separate arguments or use shell expansion.

History

History is available for local Cloud storage, where Cloud grants govern the whole area. FreeIPA and other POSIX areas show a notice instead: their Unix permissions cannot be checked for historical activity. File versions remain available according to the storage root's existing version settings.

You see activity only in local areas you can currently access. A move or copy shows each location only when you can access that area. Losing access also hides your earlier actions there. Hidden activity does not change the counts or the pages you receive.

Files records folder creation, renames, moves, copies, uploads, document creation, template use, Office saves, trash and restores, version changes, and permanent deletion through the web, Cloud app, API and CLI, other apps, and agents. It also records storage creation, adoption, archiving and retirement, link creation and revocation, template administration, and administrative reads. Each selected item has its own entry; items changed in one batch share a batch ID. Moving a folder records one entry for the whole tree. Planning folder creation or finding an existing folder creates no entry.

GET /api/filesv2/activity/:activityId/batch returns the visible count for an event's batch, independently of the current search text or history page. The response is {visibleCount, complete}. The count includes the selected event and counts each visible event once, even when only one side is readable. Own recorded snapshots follow the same visibility rules as other history reads. When complete is false, show the count as “at least”: the reader reached its 500-event bound. Exactly 500 candidates also produce a lower bound. A complete count covers retained, currently visible events; it does not count descendants inside a selected folder or events removed by retention. An unknown, inaccessible, or unbatched event returns the same 404. This read returns no peer details and does not grant access to files.

Transfer entries retain the old and confirmed new paths. Copies also record the source and destination storage areas; a copy in the same folder records the new name Filegate chose. On storage with stable IDs, renames and moves keep the item identity, while a new copy has its own identity.

Files marks an operation done only with evidence. A folder that looks right could have been created by someone else. A missing source and an existing destination do not prove a move completed. A lost transfer response stays unclear, with separate observations of the old and intended new locations.

History is kept for 365 days by default. Administrators change this under Settings → History → Keep history for, from 30 to 3,650 days; the CLI and API use the activityRetentionDays configuration key. Pending entries are kept until their outcome is known. See Files history for operators.

A trash action records one entry per selected item and keeps the old location. Restoring it records a separate entry with the destination. The trash journal and history finish together. Files can recover a lost trash response from its unique trash location and matching item. An ordinary restore destination is not proof: if the response is lost, the restoration stays unresolved and a retry does not move or overwrite another file.

Version comments, restores, copies, and deletions each have their own entry. Comment updates carry a history reference in the saved version, so maintenance can confirm that specific update later. A lost restore, copy, or delete response stays uncertain. Permanent deletions and version deletions also write the security audit in the same transaction as history completion. An upload reservation and its pending history entry are saved together. Retries, lease renewal, status checks, commits, aborts, and public inbox maintenance finish that same entry from Filegate's retained result. A visitor stays a visitor even when maintenance finds the result later. The original person, channel, request, and delegated execution remain unchanged when another request resumes the upload.

An open session or a failed publication condition does not mean the upload failed. A committed receipt records completion; a confirmed abort or expiry records not_done. A missing receipt stays uncertain. The reservation and history finish in the same transaction. An unresolved reservation keeps its history beyond the normal retention period. Journals created before this feature are adopted with their stored person or link and an unknown channel.

Each new document, file created from bytes or a template, and Office save gets its own entry. Direct-write responses confirm completion; a lost response remains uncertain. Template-created files retain the template reference.

Find changes in Activity

Activity in the sidebar lists visible history across storage, newest first by day. Its filters live in the address (/app/filesv2?view=activity&base=…&who=…&what=…&when=…&q=…), so reload, back, and links keep them; an invalid value answers 400 instead of showing another filter. From a storage location, Activity opens filtered to it. The server renders the first page with the same request the browser uses for later pages. An empty page with a next cursor offers older entries and claims no absence. A failed load keeps the filters beside Try again. Today starts at midnight in your time zone, including on clock-change days.

A search in Activity matches names and old paths. Its top result shows where the item is now, from the movement chain: confirmed by stable identity, or marked probable with path evidence only. Go there resolves the item again through /api/filesv2/entries/:id or the entry endpoint, so a stale entry never opens a place the person can no longer read. An empty ordinary search offers Search in history with the same words. An old folder address can show This folder has moved when visible history records its move or a move of an ancestor folder. A location inferred from an ancestor move is marked probable and checked at the opened folder’s current address. The old address stays open until you choose Go there. Leaving the view cancels a pending Go there lookup, so its response cannot change your later navigation.

Recovery actions of a vanished item come from GET /api/filesv2/activity/:activityId/recovery, loaded beside the chain: Restore (POST …/restore, with an optional new name after a path_conflict), Move back (POST …/move-back, only for a verified stable endpoint in the same storage), Show in trash, Open old place, and Check now (POST …/recheck) for unclear entries. A recorded snapshot never grants an action; every request checks rights, identity, and journals again, and a 403 or 409 stays visible beside the action.

Message … opens Chat's New chat form with the recorded person selected, after Chat checks their current availability and your guest restrictions. You decide whether to start a chat or choose an existing one; opening the form creates no chat and sends no message. If Chat cannot open, Files shows an error; try the action again when Chat is available. Cancel stays in Chat; browser Back returns to the Files view and its history filters.

The details panel lists the four newest entries of the selected item below its versions, then older entries and All in Activity, filtered to that item. A folder includes changes to its descendants, such as uploaded files; All in Activity keeps that folder scope across reload and Back. A file keeps its exact item scope. Rows name version numbers for entries that carry a version ID, counted over the versions the list holds; the current content is the next number. An overwrite or editor save whose new revision is the file's current revision offers Restore version N for the newest retained version, through the existing version restore. In-place restoration in the details panel requires a current storage revision; without one, restore as a new file to preserve newer content. A revision is never treated as a version ID. For public links the person created, the panel shows page views, released downloads, the period's page networks when exact, networks by use, and access over time with older periods on request, for the last 30 days, next to Revoke link.

Read an execution record

View run opens Execution in Files for that history entry. It shows the recorded action, its Files result, who acted and on whose behalf, the channel, time, and the before and after paths you may read. Source context and references holds the available request and invocation references.

This page covers one recorded Files effect. It does not establish the outcome of the whole originating run, and the source conversation is not available through this record, including when someone else performed the action. Files checks your current history access whenever the page loads. Missing or inaccessible records disclose no details; a loading failure offers Try again. Reload opens the same record, and browser Back returns to the preceding Files view with its URL filters. Opening the record starts no writes or rechecks.

Public shares

Both download links and upload inboxes support an optional password of 8–256 characters. Share the password separately from the link. Visitors must unlock before seeing shared names or obtaining any transfer. Unlocking grants access for twelve hours in that browser; expiry, revocation and the creator's current permissions still apply. Reload the page to enter the password again after access expires. Existing links remain accessible without a password.

Only an Argon2id verifier (including its random salt and parameters) is stored in Postgres. Neither the password nor the verifier appears in share responses. Unlock attempts are rate-limited. The browser receives an encrypted, share-scoped HttpOnly cookie; transfers retain their existing short lease lifetime.

Inbox upload requests (start, lease, commit and abort) are limited to 120 per minute per client address across all upload links. Requests with unknown or invalid links count against the same budget. IPv6 clients count per /64 network. NAT64, Teredo and 6to4 addresses count per embedded IPv4 address. A client that controls a larger IPv6 prefix gets one budget per /64. Each file needs about two requests. When the limit is reached, the uploader waits for the time in Retry-After and then continues on its own. Other public share requests keep their limit of 10 per minute per client address.

For operators: guests behind one shared address share the upload budget. This includes NAT, VPN and one IPv6 /64 network, such as campus Wi-Fi. Under heavy shared use, 429 responses with Retry-After on upload routes are expected and are not an outage.

A share is either a download bundle of entries or an upload inbox for one folder, always inside one base. Download shares show the current contents, including later additions to shared folders. Visitors can browse those folders, download individual files, or request a ZIP.

The creator manages their links under Shares at /app/filesv2?view=shares; administrators can manage all links separately. Reading a parent folder does not reveal someone else's shares. Creators can revoke their own links even after losing access to the files. Before each new public action, Cloud checks the creator's current account, membership, storage configuration, binding, and target permissions. Revocation prevents new actions; already issued leases retain their short remaining lifetime.

Copy the public URL when creating a share: it is shown only once. Cloud stores a token hash and cannot recover the URL later. Existing URLs survive the token migration, but cannot be copied again from the overview. Link lifetimes are 1, 7, 30 or 90 days, or No expiry; the default is 30 days. An internal note stays private. A separate public note appears to visitors.

Inbox limits default to 100 MiB per file and 1 GiB in total. These defaults also apply to existing inbox links after upgrade. Total usage is cumulative for that link: deleting received files does not replenish it. Concurrent transfers reserve their declared size before starting. Confirmed aborted or expired sessions release their reservations; an uncertain outcome keeps its reservation until reconciled. The administrator view lists unresolved transfers, including after a link expires or is revoked.

Finish active uploads before upgrading. Older open sessions have no stored backend address, so Cloud cannot safely match them to the currently configured Filegate server. After upgrade they remain listed as unresolved, and their bytes stay reserved even when the current server reports no matching session. They cannot be reconciled automatically without that evidence. Changing the configured address or deleting files does not release the reservation. If the remaining budget is insufficient, the owner can revoke the affected link and create a new inbox link with a fresh budget.

Inboxes hide uploaded names by default and show only the visitor's immediate confirmation. Creators can opt to show the names of successful uploads through that inbox. This never exposes pre-existing folder contents or grants download access. Public uploads use short-lived Filegate sessions and never replace existing files. Share, trash, and public name lists provide explicit pagination.

Configure storage

Open /admin/filesv2 for Overview, Directories, Archive, Shares, and Settings. Overview shows the selected root's capabilities and available storage measurements. Directories lists identities and filesystem entries, with actions appropriate to each state. Archive keeps removed storage available for inspection and recovery. Settings contains the connection, storage paths, and local automation policy. Directory filters and search share one toolbar; the archive has its own area filter and search. Directory details show the full name, current state, root, path, and relevant ownership information. Missing directories can also be created from that dialog. The Overview refresh action updates root statistics and reloads the view; index rebuilding remains a separate, confirmed action.

Each area has its own enabled state, named Filegate root, optional relative prefix, and home, group, and archive subdirectories. The backend token stays on the server. Saved credentials are not returned to the browser. Settings changes remain a draft until saved. Discard returns to the saved configuration. Disabling an area does not delete its directories or assignments.

History → Keep history for (activityRetentionDays) sets how long Files keeps its history: 365 days by default, 30 to 3,650 days allowed. A configuration saved before this setting existed uses the default.

Filegate reports managed and execution independently for every root. Managed means that all content and namespace writes use Filegate; it enables atomic conditional publication against other Filegate operations. Keep it off when another process or an NFS client writes directly. It does not block external writers or make their writes atomic. Cloud reads these capabilities; it does not provide duplicate activation switches.

Overview also shows Stable file IDs for the root. Filegate 7 reports them (stableIds) only for roots with both index: true and managed: true; only then do Files references survive rename and move (see Refer to files and folders). Such a root needs:

• Filegate as its only writer. Read-only access, such as a backup reader or a read-only export, is fine. Filegate does not enforce this promise.
• Readable and writable user.* extended attributes on the real mount, and no hard links to indexed files.
• Backups that keep device and inode identity. Stop Filegate, then back up each root with its .filegate directory, ownership, ACLs, and extended attributes together with the complete state_dir. Restoring copies onto new inodes or another device assigns new IDs, and every stable reference into that root becomes not_found; path references survive such a restore. Test one restore before you rely on stable references.

Turning managed off later makes stable references not_found until it is on again; Filegate keeps the IDs. FreeIPA roots that users also reach over NFS, SSH, or a desktop are usually not exclusive Filegate writers and keep path references.

FreeIPA roots require execution so Filegate performs file access using the Cloud-resolved UID, primary GID, and supplementary groups. Configure the daemon's privileged execution mode explicitly according to the Filegate operator guide; an ordinary unprivileged deployment cannot switch identities. Missing execution support prevents access instead of falling back to the daemon account. Execution is distinct from ownership, indexing, and versioning. Verify the actual filesystem and export permissions; numeric identity switching does not bypass them.

Use a dedicated browser-facing Filegate origin outside the scope of Cloud cookies. Different ports alone do not isolate cookies. Direct ZIP downloads use a native form that cannot suppress cookies for its destination. Keep the exact Cloud origin in Filegate's CORS configuration. The SDK uses the configured backend address for server-side transfers while browser leases retain Filegate's public origin.

Cloud storage requires enabled local Linux identities. FreeIPA storage requires enabled FreeIPA and valid POSIX identities. The two areas work independently. Only groups with a GID have file storage; logical groups remain available for other Cloud features. Effective group memberships include nested groups and allow FreeIPA users to access local Cloud groups.

Existing Cloud directories require explicit administrator assignment. For FreeIPA, a directory at the expected configured path is recognized after its identity and Unix permissions have been checked. It need not have been created through Cloud. Durable assignments prevent a new account with a reused name from inheriting a previous account's directory.

Create and reconcile directories

Use Create beside a missing home or POSIX group directory. Cloud directories belong to the Filegate service account; Files does not assign local Linux IDs to those files. Optional automatic creation provisions missing Cloud storage when an eligible user accesses it. It does not take over an existing unassigned directory or recreate storage that an administrator has retired or archived.

FreeIPA creation is always explicit. Files supplies the identity's real UID and primary GID for homes, or the group's GID for shared directories. Shared directories use setgid and a default ACL so future subdirectories remain traversable and ordinary files do not acquire execute permission. An existing directory is inspected rather than overwritten or recursively chmodded.

The directory inventory can be searched and filtered by state. A directory without a matching identity is an orphan only after an authoritative check. For FreeIPA this check queries the upstream identity service independently of Cloud's synchronization filters. The FreeIPA service account needs visibility of all relevant identities. A failed check remains Unknown. Conflicting ownership or a reused account name requires investigation before assignment.

Archive, restore, and delete

Archiving moves a directory within the same Filegate root, into a unique entry under the configured relative archive path. The archive path must remain inside the area's prefix and outside its active home and group trees. Its private container prevents ordinary Unix users from traversing archived data, while the archived subtree retains its original ownership and ACLs for restoration.

The Archive view lets administrators inspect files, download individual files, restore to the original path, or delete permanently. Restoration never overwrites a directory already occupying the original path and requires a matching, eligible current identity. Archived data remains inspectable when that identity no longer exists. Permanent deletion requires confirmation of the exact target path and removes its Filegate history. The administrator browser can inspect the reserved trash directory; ordinary users cannot perform permanent deletion.

Optional automatic archival applies only to previously assigned Cloud directories whose local identity has been deleted or whose group is no longer POSIX. It does not archive FreeIPA directories. Disabling an account category, disabling local Linux identities, expiration, and temporary lookup failures do not prove deletion. The background worker checks bounded batches every minute and resumes incomplete directory operations. Larger installations can take several batches to complete a pass. Explicitly disabling automatic archival is respected when automatic creation is enabled.

Directory operations keep durable progress so a lost response can be reconciled against the filesystem. An ambiguous or conflicting state remains visible for administrator investigation instead of overwriting another directory.

User trash and restore operations also record their intent before moving data. Each trashed entry gets a unique destination. Entries found directly in trash remain visible after access checks even without a Cloud record; an unknown original location requires an explicit restore path. Restore never overwrites an existing destination. Pending or ambiguous moves remain visible for review.

Restoring from the trash checks the recorded item again before starting a new restore. If another item has replaced it, Files leaves the trash untouched and asks you to refresh. A restore cancelled while waiting for the storage lock does not move the item.

Multi-entry moves, copies, and trash actions report results per item. Selecting a folder and one of its children processes the folder once. Successful items remain completed when another item fails; retry only the failed items. A batch is not an atomic transaction.

Refer to files and folders

Other apps keep a Files entry as a filesv2.entry ref, for example a Spaces link, a Grids resource field, Assistant App data, or a copied reference from the details panel. Files hands out one of these forms; treat all of them as opaque:

Only the Files server mints refs, in one place. An entry that Filegate has not identified yet keeps a path ref even on a root with stable IDs. Editor (WOPI) file IDs stay path-based and are not filesv2.entry refs.

Resolving a stable ref first checks that the actor can use its base, as for any path in it, and only then asks Filegate for the current path, so no answer depends on files in storage the actor cannot use. The usual path checks follow: the current path must lie inside the same base and outside its trash, and must still hold the same file. A stable ref therefore never grants access. Download links still name the checked path: if another file takes that path in the same instant, the link serves that file from the same base.

Refs saved before keep their form and their path meaning; Files does not rewrite refs that other apps stored. The same file can therefore have an older path ref and a newer stable ref. Equal refs name the same entry; different refs do not prove different files. GET /api/filesv2/entries/<id> and cld filesv2 stat return the entry's current resourceId for any ref.

A stable ref that cannot be resolved is not_found (404), whatever the reason: unknown or foreign base, unknown ID, managed turned off, a path outside the base or in its trash. If the base is one of the actor's but cannot be used, for example because of a binding conflict, every ID in it answers like any path there: 403 with the reason. Storage outages and network failures stay unavailable (503), so a short Filegate outage never looks like a deleted file. After resolution, the path checks answer as for any path, for example 403 when FreeIPA Unix permissions deny the file. /app/filesv2/ref/<id> opens the entry wherever it is now. Copy Cloud reference puts that link on the clipboard as plain text for stable refs; for path refs the text is a link to the folder with the entry selected.

Understand the source of truth

The filesystem determines which files and directories exist. Filegate's index is derived metadata, not a prerequisite for recognizing externally created directories. An administrator can create a FreeIPA directory directly on the storage server and then inspect it in Files. A missing Cloud assignment must not hide a valid directory.

Cloud identities determine who may use storage. Files checks current access before each operation or lease. Filegate then enforces the bound FreeIPA Unix identity during traversal, content reads, mutations, historical reads, and ZIP streaming; it does not fall back to privileged reads. A denied ZIP entry fails the archive rather than silently omitting a file. The admin inventory distinguishes missing directories, unassigned directories, conflicts, and unavailable checks. An identity missing from Cloud's filtered FreeIPA mirror is not proof that it was deleted in FreeIPA. FreeIPA directory listings and filename searches use the current filesystem under the user's Unix identity, even when the root has an index. A new search sees external changes without rebuilding the index. An unreadable subtree fails the search instead of returning partial results. Each continuation rechecks traversal and parent read permissions: revoked access fails with 403, and an externally deleted result fails with 404. Restart the search without a cursor for a fresh observation; never treat those failures as an empty page. Inventory scans return a cursor when their time budget is exhausted. Slow or cancelled FreeIPA checks remain unknown; they never authorize archival or deletion. Use the next page to continue a partial scan.

Edit office documents

Files opens text documents, spreadsheets and presentations (odt, ods, odp, docx, xlsx, pptx) in Collabora Online for collaborative editing. Administrators enable it in the Files settings by entering the Collabora address browsers load the editor from. Two optional advanced fields cover deployments in which this application reaches Collabora under a different address, or Collabora reaches Cloud under a different address than the public one. Leaving the Collabora address empty disables editing without touching existing files.

Once configured, office files open in an editor view that fills the main area, and the plus menu offers a new text document, spreadsheet or presentation. New documents start from an empty template in the configured default format: OpenDocument unless the administrator selects Microsoft Office formats. New text documents and spreadsheets print on A4 portrait in every language; Collabora takes the paper for presentation notes and handouts from the Cloud language. Users who may only read a FreeIPA file get the editor in view mode.

Collabora talks to Files through WOPI under /api/filesv2/wopi. The editor token it receives names one user and one file and carries no rights: every WOPI call resolves the user and the current permissions again, so revoked access ends a session at its next call and no instance keeps editor state. Document bytes move between Filegate and Collabora on the server side through the configured backend address; the Filegate token never leaves the backend. Every save replaces the file in Filegate, and the root's versioning policy decides which saves become versions. On managed roots, saves bind a fresh revision and Filegate atomically rejects a changed destination at publication. Cloud serializes publications (upload commits, renames, moves, version restores, and document saves) with the root lock, shared with trash and administrative lifecycle operations. Publications and trash removal and restore wait up to five seconds per request for a busy root lock before returning a retryable busy error. A move or removal of several entries shares that one wait. Administrative lifecycle operations and background maintenance still answer busy at once; trash listings do not wait for the lock. The upload queue automatically retries such a busy commit with backoff. Public inbox commits do not take this lock. Large upload commits hold both Filegate's root mutex and Cloud's root lock, so other changes in that storage wait or retry until filegate#6 is fixed. WOPI timestamp checks retain microsecond precision. Collabora's explicit Overwrite choice remains supported, while changes during that save still conflict. Unmanaged roots also recheck timestamp and size before writing. External NFS writers do not participate in the Cloud lock and remain outside its guarantee.

The editor uses the Cloud theme when opened, even if Collabora saved a different UI preference. An open Collabora editor keeps its initial theme; close and reopen it after a theme change. It is never reloaded automatically while editing.

The editor also opens in the Cloud language. Collabora uses it for its menus and for spellchecking text that does not set its own language, so new documents carry no language and are checked in the Cloud language.

Several Collabora instances need sticky routing on the WOPISrc parameter, which is a Collabora deployment concern; Files scales horizontally unchanged.

Download files

For each download, the browser requests a short-lived lease from Files. After authorization, Filegate sends the file directly to the browser. The full Filegate token never appears in the lease. Disabling an area or removing access prevents new leases; already issued leases retain their short remaining lifetime.

Play videos

Videos (.mp4, .m4v, .mov, .webm, and .ogv) play in the preview dialog and in the details panel with the browser's own controls. The browser streams the video from a download lease by range requests, so a video of any size starts at once and seeks without loading the whole file; Filegate answers each range with 206 Partial Content. When a lease expires during playback, for example after a long pause, the player requests a fresh lease through Files and continues at the same point. Every renewal passes the same access checks as a new download.

Files does not transcode. Whether a video plays depends on its codec and the browser: H.264 and VP9 play in most current browsers, while HEVC (H.265) plays in Safari but not in every other browser. A video the browser cannot play shows a notice with Download in the same frame, also when the browser could play only its sound. When Files cannot issue a lease, the same frame shows the error with Retry.

The preview frame keeps its size while the video loads, and the picture fits it uncropped: a vertical 9:16 reel shows at the dialog's full height, and on a phone the dialog fills the screen. The details panel shows the video in a square frame. The browser reaches Filegate's public origin directly; its CORS configuration must allow Cloud's origin, as for every other download.

Filegate owns each root's index, versioning, managed, and execution configuration. Files reads those capabilities independently for each root. Root file counts, directory counts, and sizes are shown only for a complete observed scan; incomplete totals or totals of unknown freshness remain unknown. Observation metadata identifies the source and scan interval. These are not live quota measurements, and root totals must not be interpreted as totals for a configured prefix.

Use the CLI

The same operations are available through cld filesv2. Sign in with cld login --server <Cloud URL>. Commands use shell-like verbs and address files as <area>:/path: me is your personal area, and a group area is its exact group name or group ID. cld filesv2 ls lists your areas with their IDs; a full area ID such as cloud:groups:<uuid> also works as the area. A file ID, the resourceId from stat --json, works in place of any file address, including a stable n:… ID.

cld filesv2 ls --json
cld filesv2 ls me:/Documents --sort modified --order desc --json
cld filesv2 tree team:/Projects --depth 2
cld filesv2 stat me:/Documents/report.pdf --json
cld filesv2 cat me:/Notes/todo.md
cld filesv2 get me:/Documents/report.pdf ./report.pdf --json
cld filesv2 put ./report.pdf team:/2026/Q3/ --parents --json
cld filesv2 mkdir -p me:/Documents/2026
cld filesv2 mv me:/Documents/draft.odt me:/Documents/final.odt
cld filesv2 cp me:/Documents/final.odt team:/Shared/
cld filesv2 rm me:/Documents/old.txt --yes
cld filesv2 trash restore me <trash-id> --json
cld filesv2 versions list me:/Documents/report.pdf --json
cld filesv2 shares add me:/Documents/report.pdf --title "Report" --expires-in 7d --json
cld filesv2 shares revoke <share-id> --yes
cld filesv2 documents create me:/Documents/Minutes --kind text --json
cld filesv2 edit-url me:/Documents/Minutes.odt
cld filesv2 favorites add me:/Documents --json
cld filesv2 admin inventory --storage freeipa --kind groups --json
cld filesv2 admin configuration set --input-file ./filesv2.json --json
cld filesv2 admin adopt <identity-uuid> --storage cloud --kind users --yes
cld filesv2 admin directories create <identity-uuid> --storage freeipa --kind groups --yes
cld filesv2 admin directories archive freeipa/groups/editors --yes
cld filesv2 admin archives list --storage freeipa --json
cld filesv2 admin files ls freeipa/archive/<archive-uuid>:/Documents --json
cld filesv2 admin archives restore <archive-uuid> --confirm-path groups/editors --yes
cld filesv2 admin shares revoke <share-id> --yes

Names are matched exactly and never guessed. When a name matches several areas, for example a Cloud and a FreeIPA group with the same name, the command fails with status 409 and lists every candidate with its ID. ls does not offer personal Linux groups as areas; such an area stays reachable by its full area ID.

ls returns one folder page. Use --json to preserve metadata and the next cursor; pass that cursor unchanged as --after with the same folder and sort options. ls and search accept --sort name|modified|size, --order asc|desc, --type all|files|directories, and --no-group-folders. search <folder> [query] also accepts --sort relevance (the default with a query), --match fuzzy|exact, --in path|name, --ext pdf,docx, --min-size and --max-size in bytes, and --modified-after and --modified-before as RFC 3339 times; a filter makes the query optional. JSON output carries total and each item's highlight. --jsonl emits one complete item per line for lists. tree follows every page down to --depth levels and stops with an error above 10,000 entries.

get and cat --out stream directly from Filegate to a new local file and never overwrite an existing path; their structured result contains only path and bytes. get downloads a folder as a ZIP. cat prints UTF-8 text up to 50 MiB and refuses binary content. The CLI must be able to reach Filegate's public download address. put needs --replace to replace an existing file. rm moves entries to the trash and needs --yes; mv renames or moves only inside one area. Multi-entry commands exit with status 1 when any entry failed.

Administrator commands use the same permissions as the UI. Configuration updates accept a complete JSON configuration through --input-file or --stdin. Omitted or empty token keeps the existing secret; a nonempty value replaces it. The read response contains tokenConfigured and unreadable, never the token. If unreadable is true, the Files settings show a notice and both areas use disabled defaults. Restore the correct APP_SECRET to recover the saved configuration, or submit the complete configuration with a nonempty Filegate token to replace it. A save without a token fails with HTTP 409 configuration_unreadable and preserves the saved row.

Reset configuration in that notice, or cld filesv2 admin configuration reset --yes, removes the saved configuration and returns both areas to disabled defaults. The admin-only API is DELETE /api/filesv2/admin/configuration; it does not delete Filegate files. Inspect the inventory entry before assigning its existing directory with admin adopt. Use cld filesv2 <command> --help for the command's arguments.

admin directories retire stops Files access and automatic recreation while leaving existing files and Unix permissions untouched. Use archival when access through the filesystem must also be restricted. Administrator file commands address a directory as <storage>/<users|groups>/<name> or an archive as <storage>/archive/<archive-id>, followed by :/path for an entry inside it. They use the same download leases as the ordinary file browser.

Permanent deletion commands require both --yes and --confirm-path matching the complete path returned by the inventory or administrator browser. Do not derive this confirmation from an unverified directory name. A pending result means the action has not yet completed; inspect the current state and use admin operations retry <operation-id> --yes to retry after resolving the cause. Rebuild and statistics commands affect the entire Filegate root, including paths outside the configured prefix.

Uploads read bounded file segments from disk and send them directly to Filegate, with bounded retries and lease renewal. Each transfer request has a deadline sized for about 0.5 Mbit/s (64 KiB/s). In text mode, put writes progress to stderr; it writes no progress with --json or --jsonl. Cancellation requests an abort before commit. Retrying the same command with the unchanged local file and destination reuses the persisted upload identity within the receipt window. A lost commit response may already represent a published file; do not switch to a new upload identity to bypass an uncertain result.

Current scope

This version includes browsing, uploads, trash and restore, version history, public shares and inboxes, office editing through Collabora Online, storage configuration, directory provisioning and reconciliation, and administrator archive, restore, and permanent deletion. Comments and AI assistance inside the editor are not part of this version. The reserved top-level trash directory is excluded from ordinary browsing and downloads.

Files requires Filegate 7.1.0 for Unix execution, native historical copies, managed-root preconditions, retained upload results, and sorting/filtering before pagination. Follow the Filegate upgrade procedure before updating Files. This does not establish production readiness for a particular filesystem or NFS export. Unmanaged external-writer conflict safety requires separate acceptance and has no atomic guarantee.

PDF/office thumbnail conversion is deliberately omitted; no conversion proxy or preview cache is needed. The browser uses polling for updates because Filegate has no change feed. Filegate's versioning cooldown determines which automatic saves become versions.

Files replaces the removed Files (legacy) application. It never read that application's settings or storage; operators map existing storage to the ordinary root and relative-path configuration. See Deprecations and migrations.

See Deployment requirements for the Filegate and Collabora prerequisites. For the local test instances, see Monorepo development.

Markdown workspace and file templates

Markdown files (.md and .markdown, UTF-8, up to 2 MiB) open in the full workspace using the shared Markdown editor, without a separate header or inner frame. Save and Close are grouped at the right of the editor toolbar. Successful saves briefly show a check on the Save button instead of a permanent status label. Add → Markdown document creates an empty file without requiring Collabora. Save explicitly or press Ctrl/Cmd+S. Unsaved changes are guarded when leaving. A failed save retains the draft; reload the current file or save a copy under a new name. Managed roots compare the revision of the downloaded bytes at publication, so a second editor cannot silently replace a newer revision. Unmanaged roots compare observed metadata; this is not an atomic filesystem precondition. Direct external NFS editing remains outside Cloud's coordination guarantees.

Add → Template is always present and loads only templates the signed-in user can use. Select one and a new file name in the current folder. The target must be writable; an existing file is never overwritten. Editable formats open in their editor after creation. If a response is lost, inspect the destination before retrying; the same name cannot create a second copy or replace the first.

Administrators manage the catalog in File administration → Templates. Upload a file or import one from an accessible storage base. Each template stores an independent binary snapshot in PostgreSQL, with a maximum of 20 MiB per file. Changing, moving or deleting the original cannot alter that snapshot. Replacing or deleting a template leaves previously created files unchanged. Catalog lists load metadata only and use cursor pagination; snapshot bytes belong in the application database backup. Catalog upload/import is a bounded administrative operation; ordinary file transfers still use direct Filegate leases.

Template use is granted through Cloud's ordinary read permissions to users, groups (including nested membership), or all authenticated users. These grants are independent of source and destination storage permissions. No grant means administration-only visibility. Creating a file additionally checks the current target's write permissions and applies its Unix execution identity and ownership. Template permissions do not change permissions on the resulting file.

The CLI exposes templates list|show|use, admin templates list|upload|import|update|replace|delete, admin templates access list|grant|revoke, and documents create --kind markdown. put --replace --expected-revision <revision> adds a save precondition; read the revision with stat. Keep the same revision and idempotency key when recovering an uncertain upload. For unmanaged files, the observation token is fs:<modified>:<size> from the stat response.

Analyze and organize files through capabilities

Assistant code mode can discover accessible storage, list folders, search names, read file content and save analysis results back to a permitted folder. Binary streams support CSV, Excel and other formats without embedding the file in a JSON tool response. Files capability streams accept files up to 50 MiB, matching the code-mode file budget. The regular direct upload and download paths keep their own limits.

Folder creation, renaming, moving, copying, moving to trash and restoring are available through the same capability catalog. Actions follow Assistant's normal approval flow and recheck current storage access. New uploads default to creating a file; replacing a file requires its current revision. Permanent deletion is still an administrative operation, not an Assistant capability.

Use cld capabilities catalog --json for current schemas and the generic stream-read, stream-write, stream-status and stream-abort commands for binary transfers. The existing cld filesv2 CLI remains available for direct tasks.

The canonical entry.read capability returns a stable open link and a resource reference with the current name. Consumers can open a Files entry through this shared contract without constructing file paths. Reading and opening still require the current user's access.

content.read reports the media type that matches the file name, for example application/pdf for report.pdf, and application/octet-stream when the extension is unknown. Files never inspects the content for it.

Offer files to other apps

Files is a file provider: other apps can browse, open, and save files in it. When you add files in another app, for example attachments in Mail, the file chooser lists Files next to This device, and you choose files from your storage without downloading them first. The chooser shows only what you can read, and a file arrives in the other app as a copy; changing it there does not change it in Files.

Files declares fileProvider: { list: "provider.list", read: "content.read", save: "provider.save" } in its capability manifest:

• provider.list shows a person's usable storage bases as the root, under the names Files shows, such as Personal. While storage cannot be reached, the root fails with unavailable (503), even if other bases work, so an outage never looks like missing storage. Inside a base it lists readable folders first, then files, filtered by name inside the folder. A folder is writable when the person may create files in it.
• content.read opens a file, up to 50 MiB.
• provider.save creates a new file in a writable folder, up to 50 MiB. It never replaces a file or folder: an existing name fails with FILE_NAME_CONFLICT (409), also when it appears during the transfer. Other failures keep their own codes, such as insufficient_space. A retry with the same idempotency key returns the same upload.

Every call checks the person's current storage access and, on FreeIPA storage, their Unix permissions, exactly as browsing in Files does. Entry IDs are the same filesv2.entry refs as everywhere else; see Refer to files and folders.

Compose private file lists and downloads

Studio Apps can combine Files entries and stored Grids documents without copying their bytes or creating public shares. Discover the installed capabilities, list accessible bases with filesv2.bases.list, and browse with filesv2.entry.list or search a known base with filesv2.entry.search-in-base, which accepts the same match, in, sort, ext, size, and time options as the API and reports total when it is known. Keep the path and filters unchanged while passing data.next as after until null, including empty filtered pages.

Every Files item carries {type:"filesv2.entry",id} beside its metadata. Keep this ref with the row, alongside grids.document refs from Grids. Use both fields as the identity and each type's own reader/download operation. Files refs do not pin bytes or grant permissions. On roots with stable file IDs, a ref keeps naming the same entry across rename and move; elsewhere it names a base and path, so a rename or move changes it. See Refer to files and folders. Refresh stale rows before acting on them.

Listing never issues a download URL. When a user requests a file download, call filesv2.content.download with {id: selectedRef.id}. The capability calls the existing permission-aware download service and returns data: {url, method:"GET", expires}. Use the exact URL without Cloud cookies or authorization headers. It is a bearer credential valid for 60 seconds; use the storage-supplied expires timestamp. Keep it out of persisted App state, shared lists, logs, and public shares. No storage URL construction is needed. Grids documents retain their own authenticated download links.

A new lease request checks current storage membership and FreeIPA Unix permissions. A 403 is denied access; a 404 is a missing reference/file or a base no longer visible to the caller; not_file (400) rejects directories. identity_changed (409) requires refreshing access/identity state. Storage failure must remain an error rather than an empty list. After expiry or a failed transfer, discard the URL and request a fresh lease through the same capability. Stop if access is denied. An existing lease may remain usable until expiry, subject to storage checks, even after Cloud access is revoked.

Use filesv2.content.read and the authenticated capability stream mechanism when processing bytes inside code. The direct lease is for a user download, not a way around the stream budget. cld filesv2 get <file> obtains a lease and saves the file without printing the private URL; the explicit cld capabilities query filesv2 content.download command returns the lease. See App capabilities for discovery and consent.

Understand changes without a Cloud entry

In local Cloud storage, when Files notices that an item differs from its last confirmed Cloud change, the history shows what it found and when it noticed it. This can happen when you open an item, save a document, or when maintenance checks it. The cause, person and actual time of the change remain unknown.

Files can recognize a move when storage provides a stable item ID. Otherwise, a move outside Cloud appears as a missing item at its last known path. It cannot compare an item without retained Cloud history, and same-size changes can go unnoticed on storage without revisions. An unfinished Cloud operation is resolved before Files records a separate observation.

Administrators can export history as CSV or JSON Lines. Each export is limited to one calendar year and 100,000 entries, and is recorded in the security audit. For filters, cancellation and privacy considerations, see Files history operations.

Administrator history exports include local Cloud areas only. POSIX-only events are excluded from counts and downloads; cross-area operations include only their local side.