Core FTP is a desktop client for moving files between a local computer and a remote server. It can connect through FTP, FTPS or SFTP, display local and remote folders side by side and queue uploads or downloads. Core FTP does not host files itself. The server account, protocol and permissions determine which folders the user can reach and what changes the client may make.
Protocol must match
FTP, FTPS and SFTP are not three names for the same connection. SFTP runs through SSH, while FTPS adds TLS to FTP. A server listening for SFTP will not accept an FTPS choice merely because both protect credentials.
The site entry needs the host, port, user name and authentication method that the server expects. A timeout can mean a wrong port, firewall block or unavailable server. Repeatedly changing the password does not solve those network causes.
Host keys identify servers
An SFTP connection can present a host key that identifies the remote server. The first connection needs verification against a fingerprint obtained through a trusted channel. Accepting any unfamiliar key trains the client to trust a server that may not be the intended endpoint.
A changed key may follow a legitimate server rebuild, but it can also indicate redirection or interception. Core FTP cannot decide which explanation is correct. The server administrator must confirm the new fingerprint before the stored key changes.
Queues separate planning
A transfer can begin immediately or enter the queue. The queue lets the user review several paths, change order and start the group together. This helps when a site update contains files scattered across several local folders.
Remote and local folders can contain identical names with different contents. An overwrite rule that applies to the whole queue can replace a newer destination with an older source. Core FTP needs a deliberate answer for overwrite, resume and skip behavior before an unattended batch starts.
Permissions stop transfers
A successful login does not guarantee write access everywhere. The account may read a web folder but lack permission to create, rename or delete inside it. Server-side quotas and file ownership can also stop a transfer after other files in the queue succeed.
That partial result matters during deployment. Uploading new page files while an old supporting file remains can leave the site inconsistent. The queue and log should be checked for every failed item rather than treating one successful upload as proof that the batch completed.
Schedules need a machine
Core FTP Pro can turn queued transfers into scheduled tasks. The computer must remain powered on, its task scheduler must run and the account needs permission to start the job. Saved credentials and network access must still work at the scheduled time.
An unattended job can fail after a password change or server outage without anyone watching the interface. Logging to an existing writable path creates evidence for the next review. A schedule also needs a clear overwrite policy, because recurring uploads can encounter yesterday’s destination files on every run.
Synchronization needs direction
File transfer is not automatically a backup. Deleting or overwriting the remote copy may remove the only good version if no separate history exists. Before mirroring folders, the user should decide which side is authoritative and how deletions propagate.
Core FTP handles the chosen transfer operations, while retention belongs to the storage design. A test folder and a dry run with noncritical files expose path, permission and overwrite mistakes before a scheduled task reaches production data.
