#Files Storage토론 중인 항목 5개

A couple of these are flipped, and sorting them out explains the mismatch. There are actually THREE different file models in Salesforce, and they store their bytes in different places: 

1. Classic Documents (the Document object): these live in Document folders (the Documents tab) and are NOT linked to a record. People use them for things like email-template images, logos, mail-merge templates. The bytes are in the Document Body field. So it is the reverse of what you had, Documents are the ones NOT tied to a record. 

2. Classic Attachments (the Attachment object): these ARE linked to a specific record, via ParentId (an Attachment must have a parent). The bytes live in the Attachment Body field. So Attachments are the record-linked ones. 

3. Salesforce Files (the modern model): this is ContentDocument (the file) plus ContentVersion (each version of it, where the actual bytes live, in the VersionData field) plus ContentDocumentLink (which records it is shared to). A single File can be linked to many records, or none. This is what most 'content body' language refers to, the file binary is on ContentVersion. 

On your specific questions: 

- Do attachments have content bodies? Not in the Files sense. An Attachment stores its own bytes in its Body field, it is a separate legacy object, not part of the ContentDocument/ContentVersion model. 

- Are documents just metadata for content bodies? No, a Document has its own Body field with the actual bytes, it is not a pointer to a ContentVersion. 

Why the counts do not match: 

- Storage is split into File Storage and Data Storage. Documents, Attachments, and Files (ContentVersions) all consume File Storage, while records consume Data Storage, so a record count and a storage-MB figure will not line up. 

- Within Files, every ContentVersion (every version of a file) counts its own bytes, so one file with 3 versions consumes 3x. That alone throws off naive counts. 

- A single File linked to 5 records is ONE ContentDocument with 5 ContentDocumentLinks, counted once for storage but it can look like 5 items in related lists. 

For auditing, Setup > Storage Usage is the cleanest view, and for the Files model query ContentVersion (ContentSize) rather than counting links. 

If this helps, please mark it as the Best Answer so it helps the next person. Thanks :)

You have it right, Magic Mover COPIES attachments into Files, it does not move-and-delete, so storage temporarily doubles (both the Attachment and the new File exist). That is by design: it leaves the originals so you can verify the conversion before anything is removed. The 'option to delete' not appearing is a common snag, depending on the version that delete step either sits behind a setting or just is not surfaced in the UI you are on. 

To actually reclaim the storage, do it as a deliberate second step AFTER you have confirmed the Files exist: 

1. Verify the conversion. Confirm the new Files (ContentDocument / ContentVersion) exist and are linked to the same records, a quick report on Files or a spot-check of a few records' related lists, before deleting anything. 

2. Delete the original Attachments yourself. Since the tool is not giving you the delete option, the reliable route is Data Loader: export the Attachment object (filter to the ones already converted), then run a Delete on those Attachment Ids. Test on a small batch first. 

3. Empty the Recycle Bin. This is the part that actually frees storage, deleted Attachments sit in the Recycle Bin for about 15 days and still count against your limit until it is purged. Purge it (or they auto-purge after ~15 days) and only then does the storage number drop. 

So: the doubling is expected, the delete is a separate step you drive yourself, and storage only drops once the Recycle Bin is emptied. Run one small test batch end to end (convert, verify, delete, purge) so you are confident before doing it across everything. 

If this helps, please mark it as the Best Answer so it helps the next person. Thanks :)