The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An FTP publication job keeps incomplete data away from the live pathname by uploading to a private staging name, checking the transfer’s final reply, validating the staged file, and only then promoting it with the rename pair RNFR followed immediately by RNTO. That promotion step is what people call the atomic swap. It is a useful goal, but FTP does not guarantee it. Whether the swap is atomic depends on how your particular server implements rename and which storage sits behind it.
What the FTP protocol guarantees, and what it leaves open
RFC 959 defines FTP as a command and reply protocol. Every command must produce at least one reply, and replies are three-digit numeric codes followed by text. The standard says replies synchronize requests and actions and tell the user process what state the server is in. A robust client therefore decides what happened from the numeric code and the protocol state, not from the wording of the reply text, which varies between servers.
Two commands matter for this pipeline. STOR stores a file under a pathname the client supplies. The rename operation is a pair: RNFR supplies the existing pathname, and it must be followed immediately by RNTO, which supplies the new pathname. The IANA FTP command registry lists STOR, RNFR, and RNTO as base commands, so every conforming server should recognize them.
Recommended Free Tools
RFC 959 does not describe the server’s filesystem. It is silent on crash consistency, transaction isolation, overwrite policy, and whether a rename is atomic from the point of view of a concurrent reader. It also leaves pathname conventions to the site. The existence of RNFR and RNTO therefore tells you that a rename can be requested, not that the final name will switch atomically.
#1 Best Overall
- Entry-level NAS Personal Storage：UGREEN NAS DH2300 is your first and best NAS made easy. It is designed for beginners who want a simple, private way to store videos, photos and personal files, which is intuitive for users moving from cloud storage or external drives and move away from scattered date across devices. This entry-level NAS 2-bay perfect for personal entertainment, photo storage, and easy data backup (doesn't support Docker or virtual machines).
- Set Your Devices Free, Expand Your Digital World: This unified storage hub supports massive capacity up to 64TB.*Storage drives not included. Stop Deleting, Start Storing. You can store 22 million 3MB images, or 2 million 30MB songs, or 43K 1.5GB movies or 67 million 1MB documents! UGREEN NAS is a better way to free up storage across all your devices such as phones, computers, tablets and also does automatic backups across devices regardless of the operating system—Window, iOS, Android or macOS.
- The Smarter Long-term Way to Store: Unlike cloud storage with recurring monthly fees, a UGREEN NAS enclosure requires only a one-time purchase for long-term use. For example, you only need to pay $459.98 for a NAS, while for cloud storage, you need to pay $719.88 per year, $2,159.64 for 3 years, $3,599.40 for 5 years. You will save $6,738.82 over 10 years with UGREEN NAS! *NAS cost based on DH2300 + 12TB HDD; cloud cost based on 12TB plan (e.g. $59.99/month).
- Blazing Speed, Minimal Power: Equipped with a high-performance processor, 1GbE port, and 4GB RAM on Board, this NAS handles multiple tasks with ease. File transfers reach up to 125MB/s—a 1GB file takes only 8 seconds. Don't let slow clouds hold you back; they often need over 100 seconds for the same task. The difference is clear.
- Let AI Better Organize Your Memories: UGREEN NAS uses AI to tag faces, locations, texts, and objects—so you can effortlessly find any photo by searching for who or what's in it in seconds. It also automatically finds and deletes similar or duplicate photo, backs up live photos and allows you to share them with your friends or family with just one tap. Everything stays effortlessly organized, powered by intelligent tagging and recognition.
Where “atomic” actually comes from
The strongest documented guarantee comes from local POSIX. The Open Group’s POSIX.1-2024 definition of rename() says the call replaces an existing destination entry with the source entry, and that the destination name stays visible throughout the operation, resolving to either the old file or the new one. Its rationale describes the operation as atomic. POSIX also reports EXDEV when a rename crosses filesystems in the cases the standard covers. This is why the familiar pattern of writing a temporary file in the same directory and then renaming it works well on a local POSIX filesystem.
Linux man-pages describe the same namespace-visibility behavior for a rename that replaces an existing destination. The same page adds a caveat for NFS. If a rename fails, the client cannot assume the file was left unrenamed, because the server may have completed the rename before it crashed and then handled the client’s retry. That caveat matters directly for FTP servers that store files on network-mounted storage.
Two boundaries follow from this. First, the guarantee is about which name a reader sees, not about whether the data survives a power failure. The Open Group rationale notes that directory operations are atomic and serializable but not necessarily durable, and it describes synchronizing file contents before the rename as the usual safeguard. Second, an FTP RNTO is handled by the server’s own code. That code may map onto a POSIX rename(), or it may not. Treat the atomic swap as a property you verify on your server, as covered in the checklist below.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Rank #2
- Features
- 1. Read/Write files/folders of memory card from PC
- 2. Simple, light weight and fast
- 3. No Setup required. Simply start FTP Server and GO.
- 4. Customize Home Directory
The execution flow, step by step
Step 1: Fix the destination and the replacement policy
Decide the final pathname and whether an existing file there may be replaced. RFC 959 does not define overwrite behavior for RNTO, so one server may silently replace the destination while another rejects the request. Write your policy down and test it on the server you actually use.
Step 2: Create a unique staging pathname
Use a name that is not the live pathname and cannot collide with other jobs, for example one that includes a job identifier. Place it in the destination directory, or at least on the same filesystem, because a cross-filesystem rename can fail where a same-filesystem rename succeeds. The naming convention is your application’s choice; FTP does not prescribe one.
Step 3: Transfer to the staging name with STOR
Send the payload with STOR using the staging pathname. A typical exchange looks like this (the exact reply text varies by server, so check the codes):
Rank #3
- 【Advanced Home Data & Media Hub】For advanced home users who need phone backup, file storage, and centralized data management. Centralize family photos, 4K videos, movies, computer backups, and personal files in one place while running multiple apps for home entertainment and everyday data management. Suitable for households with growing digital libraries and multiple NAS use cases.
- 【Built for Creators, Media Servers & Advanced Apps】Powered by the Intel N100 Quad-Core CPU, 8GB DDR5 RAM, 2.5GbE networking, and dual M.2 NVMe slots, DXP2800 handles large files and heavier workloads with ease. Run Docker, virtual machines, and media server applications compatible with Plex—ideal for content creators, tech enthusiasts, and advanced home users managing 4K videos, RAW photos, personal media libraries, and multiple NAS apps.
- 【Up to 80TB for Growing Digital Libraries】 Supports up to 80TB of storage using two HDD bays and two M.2 NVMe SSD slots for family photos, movies, RAW photos, 4K videos, work files, and device backups. AI photo management supports recognition of people, objects, scenes, and locations, album organization, and duplicate photo detection. HDDs and SSDs are not included.
- 【AI-powered Home Surveillance】Turn DXP2800 into a centralized home surveillance hub by connecting compatible network cameras and storing recordings locally on your NAS. AI-powered features include Face Recognition, People Detection, and Pet Detection, helping advanced home users review important events more efficiently while managing home surveillance and personal data in one place.
- 【One data Center Across Your Devices】Keep files from desktops, laptops, phones, tablets, and other devices together instead of scattered across cloud accounts and external drives. Access, back up, organize, and share data across Windows, macOS, Android, iOS, web browsers, and compatible smart TVs—ideal for creators and advanced home users working across multiple devices.
C: STOR /releases/.upload-7f3a9c.tmp S: 150 Opening data connection (data transfers over the data connection) S: 226 Transfer complete C: RNFR /releases/.upload-7f3a9c.tmp S: 350 Ready for RNTO C: RNTO /releases/current.csv S: 250 Rename successful
Never point a reader-facing name at a file that is still being written. The staging name is the only name the upload job writes to.
Step 4: Wait for the final completion reply
A 125 or 150 reply is preliminary and only means the transfer has started. Under RFC 959, the transfer is complete when the server returns a completion reply: 226 when it closes the data connection after the transfer, or 250 when the requested file action is complete. Read that final reply, record its numeric code, and do not advance until you have it. A 426 or 451 reply means the transfer did not complete, and the staged file must be treated as incomplete.
Step 5: Validate the staged payload
Run checks on the content before promotion. Useful checks include an expected size, a parser that accepts the file, schema checks, record counts, domain rules such as valid date ranges, and a digest comparison when the producer supplies a trusted expected digest. Keep these application checks separate from metadata checks, because a file can have the right size and timestamp and still contain wrong data. FTP does not define any of these checks, so they belong to your job.
Rank #4
- Turn your Android phone into a WiFi FTP server.
- Upload and download files over local WiFi.
- Monitor transfers live with progress and speed tracking.
- Start or stop the server with a single tap.
- Secure connections with username/password login
Step 6: Optionally confirm server metadata
RFC 3659 adds SIZE and MDTM, and the machine-readable listing commands MLST and MLSD. Discover support with FEAT before relying on them; a server that does not advertise a command may reject it. If you compare sizes, use binary (TYPE I) transfers, because the size reported for ASCII-mode transfers is not guaranteed to match the byte count. Metadata can confirm that the object exists and has the expected size and time, but it says nothing about whether the content is correct.
Step 7: Promote with the RNFR and RNTO pair
Send RNFR with the staging name and check its reply. RFC 959 expects an intermediate 350 reply, meaning the server is ready for the new name. Then send RNTO immediately, with the final name, and check for a completion reply such as 250. Do not send any other command between the two, and run the pair on a control connection that no other job uses. If RNFR fails, stop: the file still has its staging name and nothing has been published. If RNTO fails, the staged file still exists, the job is not published, and you must send a fresh RNFR before retrying.
Step 8: Reconcile any uncertain outcome
If the connection drops or times out after you sent RNTO, you do not know whether the rename happened. Before retrying, check both names. If the final name exists and matches the expected size or digest for this job, record the job as published. If the staging name still exists and the final name does not, retry the pair. If the final name exists but does not match, stop and investigate; another job may have written it. Do not retry blindly, because the NFS caveat above shows that a repeated rename can fail even though the first attempt succeeded.
Best Value
- Secure private cloud - Enjoy 100% data ownership and multi-platform access from anywhere
- Easy sharing and syncing - Safely access and share files and media from anywhere, and keep clients, colleagues and collaborators on the same page
- Automated Backup Protection - Set-and-forget backups for Macs, PCs and mobile devices to multiple destinations including cloud and external drives
- Home Security System - Record and monitor your property 24/7 with support for multiple IP cameras and remote viewing
- 2-Year Warranty - Reliable hardware backed by Synology's expert customer support team and ongoing software updates
Step 9: Clean up only what the job owns
Remove an abandoned staging file with DELE only when the job state and file age show that no process is still using it. Never delete or overwrite the final file as a cleanup shortcut. Cleanup policy is an application decision, and it should keep failed uploads long enough for diagnosis.
Job states and failure handling
Track each job through explicit states. The table below shows the state model, and the transitions are the same for any server.
| State | Meaning | Next state |
|---|---|---|
| created | Destination and staging name chosen; nothing sent | uploading |
| uploading | STOR sent; no completion reply yet | uploaded or failed |
| uploaded | Final transfer reply received and recorded | validated or failed |
| validated | Application checks passed on the staged file | promotion_requested |
| promotion_requested | RNFR and RNTO sent; reply not yet confirmed | published, failed, or outcome_unknown |
| published | RNTO returned its completion reply | terminal |
| failed | A definite error occurred before publication | terminal, after cleanup |
| outcome_unknown | Connection lost or timed out after promotion was sent | published or failed, after reconciliation |
Only mark a job published after the RNTO completion reply, or after reconciliation confirms the final name. Log the staging path, destination, server identity, reply codes, timestamps, and validation result. Never log credentials.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →The failures below need different responses. Reply codes are the ones RFC 959 uses for these conditions; your server may add its own site-specific behavior.
| Failure | Typical signal | Response |
|---|---|---|
| Login or permission rejection | 530, or a 5xx reply to STOR | Fix credentials or directory permissions. Nothing was staged, so no cleanup is needed. |
| Data connection cannot be opened | 425 | Mark failed. Check whether a partial staging file exists before retrying. |
| Transfer interrupted | 426 or 451 | Treat the staged file as incomplete. Delete it after confirming the job is inactive, then retry the upload. |
| Insufficient server storage | 452 or 552 | Mark failed. Free space or raise quota, then retry the whole job. |
| Malformed or incomplete staged file | No FTP error; detected by validation | Mark failed. Keep the staged file for diagnosis according to retention policy. |
| RNFR rejected | Commonly 450 or 550 | Confirm the staging name exists and the path is correct. Promotion did not occur. |
| RNTO rejected | Commonly 532, 550, or 553 | Staged file remains. Resolve permission or replacement policy, then send a new RNFR and RNTO pair. |
| Disconnect after RNTO was sent | No reply received | Set outcome_unknown and reconcile both names before any retry. |
| Metadata command not supported | 500 or 502, or absent from FEAT | Skip that check and rely on application validation. Do not treat it as a publication failure. |
| Staging on another filesystem | Rename fails; the local POSIX analogue is EXDEV | Move staging to the destination filesystem and rerun the job. |
Checking the atomic swap on your own server
Do not assume the swap is atomic because the server supports RNFR and RNTO. Verify these points on a test system that matches production, including mounts and storage type:
- Confirm that the staging and final directories are on the same filesystem and mount. On a Linux host you can compare device IDs with
stat -c %d. - Replace an existing file with
RNTOand record whether the server accepts, rejects, or merges the request. - While a reader repeatedly fetches the final file, run the swap. Confirm the reader gets either the complete old file or the complete new file, never a partial one.
- Find out what storage sits underneath. NFS mounts and object-storage gateways can change the rename behavior, and the Linux NFS caveat applies to them.
- Decide whether durability matters for your data. If it does, confirm that the server or application syncs file contents before the rename, because atomic visibility alone does not protect against power loss.
- Record the server software and version alongside your test results, since the behavior can change between releases.
Scope: plain FTP, FTPS, and SFTP
This pipeline and the RFC 959 and RFC 3659 references describe plain FTP. FTPS adds TLS to the same command set, so the commands and reply codes carry over, but the security setup differs. SFTP is a different protocol with its own file operations, and it does not use RNFR and RNTO. Do not apply these steps to SFTP without checking its own rename semantics.
Quick Recap
“
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
