Provides utility functions for working with attachment paths.
| Function |
Description |
| getAttachmentFilePath |
Retrieves the file path for an attachment within a note. |
| getAttachmentFolderPath |
Retrieves the attachment folder path for a given note. |
| getAttachmentFolderPathSyncOrNull |
Retrieves the attachment folder path for a given note synchronously, when that is possible at all. Obsidian builds its file/folder context menus and evaluates a command’s checkCallback synchronously, so a caller deciding whether to merely offer a command cannot await getAttachmentFolderPath. This is the synchronous twin such a caller can use instead. The answer is null when it is not knowable synchronously — that is, when Custom Attachment Location publishes its attachment-path API and therefore owns the resolution, which is genuinely asynchronous. null means “ask getAttachmentFolderPath”, never “there is no attachment folder”. Otherwise the answer is exact rather than a guess: it is produced by the very same code getAttachmentFolderPath runs, whose only asynchronous step — creating a missing attachment folder — is unreachable on this path. There is deliberately no context parameter: AttachmentPathContext only ever reaches that plugin’s resolver, and this function answers null whenever it is published. |
| getAvailablePathForAttachments |
Retrieves the available path for attachments. |
| getCheckIsAttachmentUnitFolderFunction |
Reads the attachment-unit-folder designation Custom Attachment Location publishes through its plugin API. The designation is one plugin’s setting but every relocating plugin’s business, so it is read from the same API that answers the attachment path itself. Reading it here rather than having each caller look for the plugin is the point — a folder kept whole by one plugin and torn apart by another is exactly the failure findAttachmentUnitFolderPath exists to prevent. undefined means nobody published a designation, the same “nobody owns this policy” answer that sends getAttachmentFilePath to Obsidian’s own resolution. It is distinct from a designation that answers false for every folder. The registry is looked up once, when this is called, so a caller walking a folder’s ancestors asks the same API all the way up. |
| hasOwnAttachmentFolder |
Checks whether a note’s attachment folder is specific to that note rather than shared with its siblings. The answer is derived by comparing the note’s attachment folder with the one a same-folder sibling note would get: they differ only when the folder depends on the note’s NAME. Every built-in attachmentFolderPath mode — the vault root, a fixed folder, the note’s own folder (./), a subfolder of the note’s folder (./sub) — is shared by every note in that folder, so it answers false; true arises from Custom Attachment Location’s resolver deriving the folder from the note’s name. This is the distinction a caller needs before sweeping an attachment folder wholesale: only a note-specific folder can be treated as belonging to the note. |
| isAtProperAttachmentPath |
Checks whether an attachment already sits at its proper attachment path. Returns true when the attachment’s current path is, within its proper attachment folder, either the proper base name or the proper base name plus an Obsidian deduplication suffix (a space followed by digits, e.g. img 1) with the same extension. The proper path is computed via getAttachmentFilePath with GetAttachmentFilePathParams.shouldSkipDuplicateCheck set to true (the target before any deduplication suffix), and the comparison respects the file system case-sensitivity flag (getDataAdapterEx(app).insensitive) that getSafeRenamePath uses. This lets a caller recognize a deduplication-parked attachment as already-collected, so a “needs move?” decision made against the deduplication-free proper path converges instead of re-scheduling the file forever. |