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 a plugin installed GetAvailablePathForAttachmentsFunctionExtended.extended 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 an GetAvailablePathForAttachmentsFunctionExtended.extended override, and this function answers null whenever one is installed. |
| getAvailablePathForAttachments | Retrieves the available path for attachments. |
| getCheckIsAttachmentUnitFolderFunction | Reads the attachment-unit-folder designation an attachment-location plugin published on the vault. The designation is one plugin’s setting but every relocating plugin’s business, so it rides the same seam that already carries that kind of answer: a member hung off the patched Vault.getAvailablePathForAttachments. Reading it here rather than consulting any one plugin’s settings 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 the GetAvailablePathForAttachmentsFunctionExtended.extended member gives. It is distinct from a designation that answers false for every folder. |
| 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 a GetAvailablePathForAttachmentsFunctionExtended.extended override that derives the folder from the note’s name (what an attachment-location plugin produces). 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. |