File Compact

Rewrites a FileMaker file without its free and fragmented blocks, using FMDeveloperTool --copyCompress. This is how disk space is reclaimed after large deletions or years of a database growing — the data is unchanged, the file is just smaller. Runs via AWX.

AWX template: Generic - FMS File Compact Primary use: Reclaim disk space taken by a bloated .fmp12.

Mac servers are not supported. Servers in the macs_fms group will not appear in the client/server selection for this workflow.

FMDeveloperTool cannot read an open file. If you compact a live database, FileMaker Server closes it first and clients are disconnected from it until it is reopened. How long that lasts depends on which result you choose — see Downtime.

All pages in this flow show an Experimental warning banner.

The wizard has five steps:

Select a client
Select the host
Select the file
Choose what happens to the compacted copy
Review and run

1. Select a client

Choose the client group whose server holds the file. Every client with at least one server you can access is listed — a deploy chain is not required, because a compact runs against a single host.

2. Select the host

Choose the FileMaker Server the file lives on. Only servers you have access to within the selected client are shown. Production servers display a red badge.

3. Select the file

A compact addresses its source by full path, so the file does not have to be hosted. Two tabs:

Backup file — the server’s backup directory, in the same browser Host from Backup — On-Server uses. Nothing that is hosted is touched. Use a full backup; a progressive backup gives no reliable sign that it has finished being written.
Live hosted file — the databases FileMaker Server is currently serving. This is the only source that can be swapped (step 4), and the only one that involves downtime.

4. Choose what happens to the compacted copy

This is the whole shape of the run. Three choices:

Leave it in the staging folder

Nothing is hosted and nothing is replaced. The job reports how much the compact reclaimed, and leaves the copy on the server for you to inspect, download or host yourself.

Use this to find out what a compact would buy you before committing to one — on a backup, it costs no downtime at all.

Host it beside the original, under a new name

Opens the compacted copy on the same server alongside the file it came from. Defaults to the original name plus _compacted.

This is create-only: a name that is already hosted is refused, and you are asked to pick another. Replacing a hosted file is what the third option is for.

Externally stored container data lives in a folder keyed on the database name, so container fields in a copy hosted under a new name will not resolve. If the file uses external containers, swap instead.

Replace the source file with it

Hosts the copy under the source file’s own name, replacing the live database. This is the only result that actually reclaims the space on the server — the other two leave the original where it is.

Offered for a live source only: a backup is not a database the server hosts, so there is nothing there to replace.

The file keeps its name, so external container data and any client file references keep working. The file being replaced is backed up first to a timestamped folder under pre-compact-backups/ unless you turn that off on the review step — leaving it on is what makes the swap reversible.

5. Review and run

The review step connects to the server to size the file, read disk usage, and (for a new name) check that the name is free. It shows:

the host, the source and its size, and what the result will be;
a downtime warning when the source is live, worded for the result you chose;
a disk space card with the capacity policy’s consent checkboxes;
for a swap, the Back up … before replacing it option;
for staff, the exact AWX extra vars that will be submitted.

Both the disk decision and the name check are re-made at launch, against the server as it is at that moment — not against the page you are looking at. A review page left open while the disk filled up will be refused, not waved through.

Press the run button to submit the job. You land on a progress page that polls AWX, shows what is currently running, and offers Cancel job. When the job finishes it prints the role’s summary: the source size, the compacted size, how much was reclaimed, and what the copy was hosted as.

While it runs

Compacting a multi-GB file can take hours, so the role does not hold a connection open for it: FMDeveloperTool is launched detached on the server and then polled until it reports back (the same is done for the pre-replace backup and a cross-volume move). The role allows 12 hours for a compact and 2 for a copy, and moves on the moment a step finishes.

That is what the progress page’s current-task line reflects. Rather than name the poll task — which is plumbing, and would sit unchanged for hours — it names the work being waited on and how many times it has been checked:

Compact /db/Live.fmp12 to /db/staging/Live.fmp12 — running detached, checked 42 times

A rising count is the sign the run is alive. The checks are 30 seconds apart, so it is also roughly how long the step has been going.

Two consequences of the work being detached:

Closing the page does not stop the job. It finishes on the server and lands on the History page either way.
Cancel job does not stop a compact that has started. It stops the playbook, not the copy already being written — so the source is left closed and nothing is hosted. Check for a live FMDeveloperTool process on the server before re-running, and reopen the file yourself if the run was a swap.

Downtime

Source	Result	The file is closed…
Backup	any	never — nothing hosted is touched
Live	staging, or new name	while the copy is written, then reopened immediately
Live	replace the source	from the start of the compact until the copy is hosted

A swap keeps the database offline for the whole job, not a moment: the compact, the backup, the move and the reopen all happen while it is closed. On a multi-GB file that is hours, not minutes. On a production server, do it in a maintenance window.

Disk space

A compact writes a full-size copy of the source before anything is moved, so the volume needs room for roughly another copy of the file. The portal projects that against the same three-tier policy every other write uses (see Overview), charging:

the source’s size for the copy — the compacted file is smaller, but by how much is exactly what the run is being asked to find out, so the original’s size is the only honest upper bound;
plus another copy for the pre-replace backup, when you are swapping and have left that option on.

For a swap the card’s After figure is lower than its Peak: the copy takes the source’s place rather than sitting beside it, so its space comes back at the end. For the other two results the copy stays on disk and the two figures are the same.

The role checks free space on the server itself as well, before it writes anything.

Conflicts with other jobs

While a compact is running, the portal refuses any other operation that touches the same file on that server — including one that only reads it. That is stricter than it looks elsewhere in the portal, and deliberate: FMDeveloperTool needs the file closed, so during a compact there is nothing there to read.

History

Every compact is recorded on the History page under Compacts, with the source path, whether it came from a backup or a live file, the result, what it was hosted as, and a link back to its output.