files upload
Send Files to Amazon S3, Backblaze B2, OneDrive, Google Drive or a Local Folder
Send a file, or a whole folder, from a local remote to an Amazon S3 remote, to Backblaze B2, to OneDrive, to Google Drive, or to a folder of another local remote (such as an external drive or a sorted archive) that you have already added. FileFortress sends them itself; there is nothing else to install or set up. Your files go straight from disk to their destination and never pass through FileFortress servers. You see what will happen first, a file that is already there is never replaced or deleted, and each file is checked once it has been sent.
Interactive Mode
Desktop GUI
Syntax
filefortress files upload <remote> <path> --to <remote> --folder <bucket-or-folder/...> [options]
remote: Name (or ID) of the local remote the files are on. Files can only be sent from a local remote.
path: A file on the local remote, exactly as filefortress ls shows it — or a folder, with --recursive. The local remote must have been scanned first.
Options
| Option | Description | Example |
|---|---|---|
--to <remote> |
Name (or ID) of the Amazon S3, Backblaze B2, OneDrive, Google Drive or local remote to send to. Not the remote the files come from. Required. Add it first with remotes add. | --to myS3 |
--folder <bucket-or-folder/...> |
Where to send the files. Required in scripts; typed at a terminal, you are asked for it when you leave it out, and for OneDrive and Google Drive you pick from every folder at the top of the drive. For Amazon S3 the first part must be a bucket your FileFortress remote is set up with; anything after it is a folder inside that bucket. For OneDrive and Google Drive the first part is a folder at the top of the drive (on Google Drive, the only folder of that name there), which must already be there unless you add --create-folder; anything after it is a subfolder, created if needed. For a local remote the first part must be the name of one of that remote’s folders as FileFortress lists it (the last part of its path, so a remote added with D:\Archive is Archive); anything after it is a subfolder, created if needed. |
--folder backups/photos or --folder Archive/2024/trip |
--create-folder |
OneDrive and Google Drive only: create the first part of --folder at the top of the drive when it is not there. If the remote was added with chosen folders, the top folder is also added to them, so its files are scanned and searchable; that is also how you send into an existing top folder outside them. Without it, a missing top folder is refused, so a typo never creates a stray folder. The preview says what will change before anything is written. |
--create-folder |
-r, -R, --recursive |
Send a folder and everything in it, including subfolders. The folder’s contents land directly in --folder. Without it, a folder path is refused. |
--recursive |
--dry-run |
Show what would be sent and write nothing. Reads no file contents. | --dry-run |
--no-rescan |
Do not scan the destination remote after sending. By default it is scanned so the new files appear in search and listing. | --no-rescan |
--non-interactive |
Run in script mode: no preview-and-confirm question, and fail rather than prompt for anything missing. | --non-interactive |
Before You Start
There is nothing to install and no link step. Sending needs two things:
- A local remote that has been scanned, holding the files you want to send.
- A remote to send to that you have already added: either an Amazon S3 remote, with the keys saved for it (FileFortress uses those keys to upload, and they must be allowed to write: read-only keys are refused by AWS, and the message says so), a Backblaze B2 remote, with the key saved for it (it must be allowed to list, read and write files), a OneDrive remote, with the sign-in saved for it (it must have write permission), a Google Drive remote, with the sign-in saved for it (it must have been added with full access), or another local remote, which is a folder on this computer such as an external drive. See remotes.
What Happens When You Send
- Compare. FileFortress compares each file with the destination. This writes nothing and reads no file contents; it is all a preview or
--dry-rundoes. - Send. Only the files the comparison found missing are sent, straight from your computer to the destination. For Amazon S3, large files, such as phone videos of several GB, go up in parts, up to four at once.
- Check. Every file that was sent is compared with what was stored: for S3, with what AWS stored; for OneDrive, with the quickXorHash checksum OneDrive reports for what it stored (checked by size only if OneDrive shows no checksum); for Google Drive, with the SHA-256 checksum Google reports for what it stored (MD5 if it shows no SHA-256, by size only if it shows neither); for Backblaze B2, with the CRC64NVME checksum when Backblaze returns one (checked by size only if it does not); for a local folder, a SHA-256 checksum of what was read is compared with the written copy, read back. The copy keeps the original’s modified time.
- Rescan. The destination remote is scanned so the new files appear in search and listing. Use
--no-rescanto skip this.
What Gets Checked
Create only. A send never deletes, moves, syncs or replaces a file that was already there. The only thing it ever removes is its own unfinished upload, for example after you stop it. An existing file is never replaced and is reported as not replaced. For S3, every upload asks AWS to refuse it if a file of that name already exists; for a local folder, an existing file is left exactly as it is.
Each file is given one of these labels:
- Would send — shown by a preview or
--dry-run: the file is missing at the destination and would be sent. Nothing is written. - Checked by checksum — the file was sent, and the checksum stored for it (AWS’s for S3; for a local folder, one computed from what was read) matches your file on disk. This catches damage in transit; it is not a defence against deliberate tampering.
- Checked by size only — the file was sent and the stored size matches, but the destination showed no checksum to compare.
- Failed — the file could not be sent, or what was stored does not match. The reason is shown.
Files that were not sent are labelled too:
- Already there, identical — a file of that name exists and its size and checksum match, so it was not sent.
- Already there, same size; content not compared — a file of that name exists with the same size, so it was not sent. The destination showed no checksum, so its content was not compared.
- Exists but different — not replaced — left exactly as it was.
- Not sent — skipped, with the reason (see the limits below).
If any file ends up failed, not replaced or not sent, the command reports that some files were not sent and exits with an error code. Files that did arrive stay where they are; run the same command again to send the rest.
Sending a Folder
- Without
--recursive, a folder path stops with a message pointing you to--recursive; a single file needs no option. - With
--recursive, every file under the folder in your local index is considered. The folder’s contents land directly in--folder— the folder you named is not created again inside it. - Only files in your latest scan of the local remote are included — scan it first if you have added files since.
- For Amazon S3, the first part of
--foldermust be a bucket the remote is set up with. FileFortress refuses any other bucket and never creates a bucket. Only buckets owned by the AWS account your keys belong to can be sent to; a bucket shared from another account cannot. - For OneDrive, the first part of
--folderis a folder at the top of your OneDrive, and FileFortress creates the subfolders below it. It creates that top folder only when you ask (--create-folder, or + New folder… in the desktop app). If the remote was added with chosen folders, files are only sent inside those folders, unless you ask for a new top folder: it is then added to the remote’s folders before any file is sent. Shortcuts to folders someone shared with you are not sent into. - For Google Drive, the first part of
--folderis a folder at the top of My Drive, and the only folder of that name there; FileFortress creates the subfolders below it (where two subfolders share a name, the older one is used), and creates the top folder only when you ask, as for OneDrive. If the remote was added with chosen folders, files are only sent inside those folders, unless you ask for a new top folder, which is then added to them. Shortcuts are never sent into. - For a local remote, the first part of
--foldermust be one of that remote’s folders; subfolders after it are created. A destination inside the folder being sent from, or one that contains it, is refused, and so is sending to the same remote the files come from.
Confirmation at a Terminal
When you type the command at a terminal, FileFortress first shows the preview, then asks:
Send 12 file(s), 48.2 MB, to myS3 in backups/photos?
Nothing already there is replaced, and nothing is deleted.
Type y to send or N to cancel:
Only y sends; any other key cancels and nothing is written. The question is skipped — the send runs straight away — with --non-interactive, and when the output goes to a file or another program, because FileFortress treats both as scripts. Use --dry-run in a script if you want a preview without sending. Even if a file has appeared at the destination since the preview, it is never replaced.
Press Ctrl+C to stop a send. FileFortress removes the unfinished upload (or unfinished local copy) before it exits, which can take up to about 40 seconds on a slow connection. Closing the terminal window instead leaves it behind (see the lifecycle rule under Limits). Files that had already arrived stay where they are. An interrupted file is sent again in full the next time.
Limits
- Only Amazon S3, Backblaze B2, OneDrive, Google Drive and local remotes can be sent to so far.
- The source must be a local remote. Encrypted remotes cannot be sent from or to.
- Local destinations: sending to the same remote the files come from is refused, as is a destination folder inside the folder being sent from or one that contains it. Links (symlinks, junctions) are never followed when writing. On Windows, names Windows reserves (such as CON, NUL or COM1) or ending in a dot or space are refused. A file stopped part-way is removed; only the unfinished copy that send made. Folders it created for that file stay, empty. On a network share, a mounted cloud drive or a folder a sync app manages, “never replaced” is only as good as that drive: it may not yet see a file of the same name that exists elsewhere.
- Amazon S3: only buckets owned by the AWS account your keys belong to can be sent to. A bucket shared from another account cannot.
- Amazon S3: the keys saved for the remote must be allowed to write. Read-only keys are refused by AWS, and the message says so.
- Backblaze B2: a file is never replaced, but Backblaze itself cannot refuse a name that is already there. FileFortress looks at the name just before sending each file (for a large file, again just before its parts are joined) and sends it only when the name is free. If something else writes the same name at that very moment, your file becomes the newest version and Backblaze keeps the other as an older version (unless a lifecycle rule on the bucket removes older versions). A file already there is compared: same size and checksum is reported as already there; otherwise it is reported as not replaced and left as it is. The first folder must be a bucket the remote is set up with. The key saved for the remote must be allowed to list, read and write files in that bucket and folder; a key that is not is refused before anything is sent, with what it lacks named.
- Files that are links (symbolic links or junctions) in the source are left out and reported as not sent.
- On Windows, files or folders whose names end in a dot or a space, or contain a colon (
:), are left out with a reason. - OneDrive: a file is never replaced. OneDrive itself refuses a name that is already there, because every file goes through an upload session that refuses an existing name. A file already there is compared: same size and checksum is reported as already there; otherwise it is reported as not replaced and left as it is.
- OneDrive: the sign-in saved for the remote must have write permission (Files.ReadWrite or Files.ReadWrite.All). The one-click OneDrive connection has it. A read-only connection is refused before any file is written, and the message names the missing permission; remove the remote and add it again with write access.
- OneDrive: empty (0-byte) files are not sent; they are reported as not sent.
- OneDrive: pressing Stop, pressing Ctrl+C, or quitting the desktop app cancels the unfinished upload, so nothing half-sent ever appears as a file. Folders created for a send that was stopped stay, empty.
- Google Drive: a file is never replaced, but Google Drive itself cannot refuse a name that is already there. FileFortress looks for the name just before creating each file (and again before the last part of a large file) and creates it only when the name is free. If another app creates the same name at that very moment, both files are there afterwards; nothing is replaced, and the result says so. A file already there is compared: same size and checksum is reported as already there; otherwise it is reported as not replaced and left as it is.
- Google Drive: the remote must have been added with full access (the drive permission). A read-only connection (drive.readonly), or one limited to the files FileFortress made itself (drive.file), is refused before anything is sent, and the message names it; remove the remote and add it again with full access.
- Google Drive: pressing Stop, pressing Ctrl+C, or quitting the desktop app leaves the unfinished upload for Google to discard; it never appears as a file. Folders created for a send that was stopped stay, empty. Empty files are sent.
- Amazon S3: if the region saved for a bucket is wrong, AWS’s real region is used for that send and the result says so.
- Amazon S3: pressing Stop, pressing Ctrl+C, or quitting the desktop app removes the unfinished upload of a large file, as long as AWS can be reached. If FileFortress is killed, its terminal window is closed, or the computer shuts down, nothing is removed. Parts left behind do not show in listings but are billed as storage. To clear them automatically, add a lifecycle rule to the bucket that deletes incomplete multipart uploads after a few days (in the AWS console, the rule action is “Delete expired object delete markers or incomplete multipart uploads”).
- There is no resume: a file whose send was interrupted is sent again in full next time.
Examples
Preview what would be sent, and write nothing:
filefortress files upload myLocal photos/2024 --to myS3 --folder backups/photos --recursive --dry-run
Compares with the destination and lists each file as would send, already there, or not replaced. Nothing is written.
Send to a folder on another local remote:
filefortress files upload phone DCIM --to archive --folder Archive/2024 --recursive
Here archive is a local remote added with a path ending in Archive; the 2024 subfolder is created if it is not there yet.
Send to OneDrive:
filefortress files upload phone DCIM --to myOneDrive --folder Pictures/2024 --recursive
Pictures must already be a folder at the top of your OneDrive; the 2024 subfolder is created if it is not there yet.
Send to a new top folder on OneDrive or Google Drive:
filefortress files upload phone DCIM --to myOneDrive --folder "Baby Pix" --recursive --create-folder
Baby Pix is created at the top of your OneDrive just before the first file is sent, or used if it is already there. If the remote was added with chosen folders, it is added to them, so the next scan lists it. The preview says which of these will happen.
Send to Google Drive:
filefortress files upload phone DCIM --to myGoogleDrive --folder Pictures/2024 --recursive
Pictures must already be the one folder of that name at the top of My Drive; the 2024 subfolder is created if it is not there yet.
Send to Backblaze B2:
filefortress files upload phone DCIM --to myB2 --folder my-bucket/photos/2024 --recursive
my-bucket must be a bucket the remote is set up with; a bucket is never created.
Send one file:
filefortress files upload myLocal photos/2024/trip.jpg --to myS3 --folder backups/photos
Send a folder and everything in it:
filefortress files upload myLocal photos/2024 --to myS3 --folder backups/photos --recursive
Send from a script, without the question:
filefortress files upload myLocal photos/2024 --to myS3 --folder backups/photos --recursive --non-interactive
Check the exit code: it is an error if any file was not sent.
Send without scanning the destination afterwards:
filefortress files upload myLocal photos/2024 --to myS3 --folder backups/photos --recursive --no-rescan
Prefer the desktop app?
Open the desktop GUI (filefortress --gui or double-click the app), go to Files, open a folder of a local remote and click Send to remote in the toolbar, next to Download folder.
- Choose a remote to send to, then pick the top folder from the list: for Amazon S3 and Backblaze B2, a bucket (shown as “Bucket”); for a local remote, one of its folders (shown as “Top folder”); for OneDrive and Google Drive, any folder at the top of the drive (FileFortress asks the drive for the list; one outside the remote’s chosen folders is marked and is added to them when you send), or + New folder… to name a new one (created at the top of the drive and, if the remote was added with chosen folders, added to them). If the drive cannot be reached, only the folders FileFortress has scanned are listed, and the dialog says so. Optionally add a subfolder inside the top folder you picked; the window shows where the files will go (“Files go to …”).
- Review the preview, which lists every file and whether it would be sent. Nothing is sent until you confirm.
- Watch the live progress and press Stop at any point. You can also hide the window; the send keeps going.
- Read the result for each file, with the same labels as the CLI. The destination is rescanned when it finishes.
Pressing Stop cancels the send and removes the unfinished upload. Quitting the app does the same, and waits for that cleanup before it closes.
Privacy
- For Amazon S3, FileFortress uploads with the keys you saved for the remote. This is the one command that uploads to your cloud account: it only creates new files, only in buckets the remote is set up with, and never deletes, moves or replaces a file that was already there (the only thing it removes is its own unfinished upload). For Backblaze B2, the key you saved for the remote is used the same way, and the files go straight from your computer to Backblaze. For OneDrive and Google Drive, FileFortress uploads with the sign-in saved for the remote, and the files go straight from your computer to your drive. A local destination works the same way on your own disk.
- Your files travel straight from your computer to their destination. They are not stored on, or sent through, FileFortress servers.
- Nothing about the transfer — file names, counts, or what was sent — is sent to FileFortress servers.