LOCAL NETWORK
Pair first. Grant only the access you intend.
Status: Preview
Nearby Sharing is a Preview capability for RFile computers on the same Wi-Fi or wired network. Its Off, On, and Auto choices control availability, but none grants trust, file access, or consent by itself.
Nearby workflow
- Choose Off, On, or Auto
Choose On for the current session or Auto to enable Nearby now and whenever RFile starts. Auto shows a small Auto on status. Accepted content defaults to Downloads\RFile, and the folder picker can choose another destination.
- Discover or invite
Use a discovered endpoint or exchange a generated invitation privately. Unknown discoveries use a generic Nearby computer label. A remembered device name appears only after its current authenticated, non-revoked trust association is verified; a friendly name alone is not proof of identity.
- Compare the code
Verify that both computers display the same confirmation code before accepting.
- Assign permissions
Enable only the send, receive, browse, write, or auto-accept capabilities you want that trusted device to have.
Control the local workflow
- Sharing mode
Off stops Nearby, On enables it for the current RFile session, and Auto enables it now and at future RFile starts. The live three-way control stays on the Nearby devices page.
- Incoming folder
Accepted content uses Downloads\RFile by default. Use Browse to select another local destination instead of typing a path by hand.
- Keep running after close
When background mode is enabled, closing the last RFile window leaves the service in the Windows notification area. Choose Open RFile or double-click the tray icon to restore it; choose Quit RFile to stop RFile and Nearby completely.
- Bandwidth limit
Set the whole-number Nearby transfer limit under Settings > Nearby & background. Enter 0 MiB/s for unlimited bandwidth.
- Cancel pairing
An outgoing or otherwise cancellable in-progress pairing attempt exposes Cancel. Cancelling ends that attempt; it does not grant trust or permissions.
Send a file or folder to a trusted device
- Confirm the connection
Use the exact trusted-device card that reports a connected local-network route and has the required Send and Receive permissions.
- Choose content
Select Send files, Send folder, or Send selection. You can instead drop an internal RFile selection or native Windows files and folders onto the eligible device card.
- Wait for consent
Unless the recipient deliberately enabled Auto-Accept for this identity, the other person accepts or declines the offer in RFile.
What is the maximum transfer speed?
RFile does not have one measured maximum MB/s figure. With the Nearby bandwidth setting at 0, the sender has no user-configured rate cap; that does not make its throughput unlimited. The slowest network link, source read speed, receiver write and commit speed, hashing, encryption, and flow-control latency constrain it.
The homepage calculator shows raw link ceilings, not app benchmarks. In decimal units, Gbps × 1,000 ÷ 8 = MB/s: 1 Gbps is 125 MB/s; 2.5 Gbps is 312.5 MB/s; 5 Gbps is 625 MB/s; 10 Gbps is 1,250 MB/s. Real file payload throughput is lower. A Wi-Fi negotiated link rate is not an end-to-end throughput guarantee, especially when both computers share wireless airtime.
In 0.3.68, V2 trusted sends currently select one lane, 64 KiB records, and a 4 MiB credit window. Shared-folder downloads negotiate their record and credit profile. A credit window limits unacknowledged bytes, not bytes per second: as a rough pipeline bound, 4 MiB returned every 10 ms represents about 419 MB/s before other bottlenecks; at 100 ms it is about 41.9 MB/s. Durable receiver work can increase that credit-return time. These calculations are not measured speeds or guarantees.
Measure elapsed time from starting the job through preparation, transfer, verification, and final publication. Divide the exact successfully transferred byte count by that complete duration. The live transfer-phase rate can be higher than this end-to-end average. Many small files pay per-file and directory overhead; a same-volume move can be a rename and is not a meaningful MB/s copy benchmark.
No current two-physical-PC LAN saturation benchmark has been published. The historical Robocopy comparison on this website is a local cross-volume copy-engine test and cannot establish LAN or Internet maximum speed.
Follow file and folder preparation
A folder offer must discover its entries, hash ordinary files, and complete final source checks before transfer can begin. The outgoing card uses the folder or selection name and labels these stages Scanning, Verifying source, and Final checks. Byte and item counts appear only when that information is available; preparation is not presented as network transfer progress.
RFile can hash separate files with a small bounded worker pool while a single file keeps a sequential path. The first offer reuses the fresh inventory proof that was just completed instead of immediately repeating the same full byte scan. Reconnects and later attempts still revalidate, and final source checks remain required.
From 0.3.68, single-file sends report live hash-byte progress and retain a mutation-denying source handle so unchanged bytes do not need repeated full hashing. Folder sends show live verification of each source file between byte transfers without counting those checks as received data.
Send and download cards share progress presentation: unknown scans and one-pass archive preparation remain animated with live counts, measured source verification shows byte progress, and a send displays Finalizing on receiver until durable completion is confirmed. A growing discovered-byte count is not treated as a whole-folder percentage.
Accept or decline an incoming offer
RFile shows a global card at the right side of the desktop when an eligible offer needs a decision. The card remains available outside the Nearby page and owns the Accept or Decline action. Unless Auto-Accept is enabled, the recipient has five minutes to decide.
Windows also shows an informational notification when RFile is in the background. It tells you an offer is waiting, but it does not accept the transfer or expose incoming filenames before consent. Accepted content is written under the configured incoming folder.
If a folder manifest offer requires manual consent while the bounded UI event queue is temporarily full, RFile retains the pending offer and retries ApprovalRequested delivery instead of falsely reporting PolicyRejected to the sender.
The sender keeps receiver declines and insufficient-space responses distinct instead of labeling every rejected offer as PolicyRejected.
Transfer path and throughput
Update both computers to 0.3.68 or later for the LAN folder reliability fix. Verified files in hidden folder staging no longer consume the 64 simultaneous receiving slots, fixing rejection of the 65th file. Recovery records, retained-state limits, and disk reservations stay enforced, and the complete folder still publishes atomically.
The shared V2 layer also handles Windows closing an already-acknowledged connection without discarding successful completion. This fixes intermittent download protocol errors after all bytes arrived; unauthenticated closes and failures before acknowledgement still fail safely.
Direct sends now use the shared 30-second control-request default instead of a five-second override to give receiver disk verification and publication more time. Manual approval retains its separate five-minute window.
When a paired LAN route is available, RFile can transfer directly between the computers instead of first uploading the file to cloud storage. Trusted-card send controls require this active LAN route.
After consent and resume negotiation, non-empty BLAKE3 trusted sends between RFile 0.3.49 or newer peers move file bytes through the same authenticated dedicated V2 bulk-lane core used by Browse Devices. Offer, consent, resume proof, final verification, and publication acknowledgement stay on the authenticated control session. SHA-256 sends and peers without the V2 capability safely keep the existing authenticated streaming path.
Outgoing trusted-device sends also appear in the global Transfers panel with the actual dedicated V2, authenticated V1, or legacy carrier; device and direction; preparation, approval, progress, speed, ETA, elapsed time, and terminal status.
The transfer rate is not fixed by a marketing number. It depends on Wi-Fi or Ethernet, storage on both computers, CPU, memory, the transport path, and the file workload.