floe receive command

floe receive <code | link>

​

Examples

floe receive olive-tiger-castle

floe receive "https://floe.one/#room=abc123..."

floe receive olive-tiger-castle -o ~/Downloads

floe receive olive-tiger-castle -y

​

Output

  Connecting to sender...
  Connected

  ─────────────────────────────────────────────────
  Incoming   2 files · 2.3 MB
  ─────────────────────────────────────────────────

  Accept? [Y/n] y
  [1/2] photo.jpg 100% [███████████████] (480 kB/s)
  [2/2] notes.txt 100% [███████████████] (14 kB/s)

  ─────────────────────────────────────────────────
  Received   2 files (2.3 MB)
  Time       5s · avg 468.0 KB/s
  Saved to   /home/user/Downloads
  ─────────────────────────────────────────────────

​

Confirmation prompt

  ─────────────────────────────────────────────────
  Incoming   N files · X MB
  ─────────────────────────────────────────────────

  Accept? [Y/n]

• Type n or no, in any capitalization, to decline. The transfer is canceled and the connection closes.
• Press Enter or type anything else to accept and begin receiving. The prompt only looks for a decline, so a typo counts as yes.

​

Flags

​

Notes

• Received files are saved to the output directory. Existing files are never overwritten: if a name is already taken, the incoming file is saved with a numbered suffix before the extension (report.pdf, then report (1).pdf), the same way browsers de-duplicate downloads. The progress line shows the name actually written.
• Each file is written under a temporary name ending in .part and takes its final name only once every byte has arrived and been verified, so nothing half-written can ever sit under a finished-looking name. A transfer that fails or stalls partway deletes its .part file; files that completed earlier in the batch are kept, and retrying reuses the original name instead of a numbered one. Even if the process is killed outright or the machine loses power, the worst leftover is a .part file, which is safe to delete (until you do, a retry saves under a numbered name). On macOS and Linux a crash at the exact instant of completion can additionally leave an empty placeholder at the final name beside the intact .part; on Windows the final rename is atomic and no such instant exists.
• Directory structure is preserved when the sender sends a folder. Files land at the same relative paths inside your output directory.
• A name your system cannot represent is adjusted before the file is written, and the progress line shows the adjusted name. On Windows that means the characters < > : " | ? * become underscores, trailing dots and spaces are removed, and a name that is a reserved device name (such as NUL) gets an underscore in front. Names are left exactly as sent on macOS and Linux, where all of those are valid. Control characters and text-direction marks are replaced with underscores on every platform, since a file name is not a place for either. A browser receiver strips them instead of replacing them, so the same file can land under slightly different names on the two surfaces.
• On Windows, received files are tagged with the mark of the web (a Zone.Identifier stream), so SmartScreen and Office Protected View treat them like browser downloads when opened.
• Press Ctrl+C to cancel the transfer at any time. The in-flight .part file is removed on the way out.
• Short codes expire 10 minutes after the sender starts the session. After that, only the full link works (and only while the sender is still connected).
• After the transfer completes, the receiver posts only the total byte count to the signaling server for the public global counter. No file names or contents are included. Use --no-report or FLOE_NO_STATS=1 to skip this. The sender never reports.