Skip to content

Add rename option for file collisions during archive#19

Open
ggfevans wants to merge 5 commits intomfarr:mainfrom
ggfevans:feature/issue-18-rename-option
Open

Add rename option for file collisions during archive#19
ggfevans wants to merge 5 commits intomfarr:mainfrom
ggfevans:feature/issue-18-rename-option

Conversation

@ggfevans
Copy link
Copy Markdown
Contributor

@ggfevans ggfevans commented Oct 15, 2025

Fixes #18

Summary

Adds a rename option when archiving a file that already exists in the archive destination, allowing users to preserve both versions.

Changes

  • Extends SimpleArchiverPromptModal to support optional third button
  • Adds generateUniqueArchivePath helper method for timestamp-based unique names
  • Updates file collision prompt from Replace/Cancel to Replace/Rename/Cancel
  • Generates unique filenames using YYYYMMDD-HHMMSS format
  • Maintains backward compatibility with existing two-button modal usage

User Experience

When archiving a file that already exists in the archive, users now see three options:

  • Replace: Trash the existing file and archive the new one (existing behavior)
  • Rename: Archive the new file with a timestamp suffix, preserving both versions
  • Cancel: Abort the operation

Example: Archiving note.md when it already exists generates note-20251014-232547.md

Design Decisions

We considered prompting the user with Obsidian's native rename dialog to let them specify a custom name. However, we chose automatic timestamp-based naming for several reasons:

  1. Minimal invasiveness: One-click rename without additional user input
  2. Consistency with Obsidian patterns: Timestamp suffixes are common in Obsidian workflows
  3. Plugin ethos: Aligns with "Simple Archiver" philosophy of streamlined operations
  4. Predictable naming: Clear, sortable timestamps make version tracking easier

The timestamp format (YYYYMMDD-HHMMSS) is human-readable, sortable, and handles edge cases like multiple renames in the same second by appending a counter.

Implementation Details

  • Modal class now accepts optional middleButtonText and middleCallback parameters
  • Button order: Primary (warning style) / Middle / Cancel
  • Timestamp generation uses ISO format, stripped of special characters
  • Path uniqueness verified before rename to prevent collisions

Compatibility

Testing

Tested with:

  • Files with extensions
  • Files without extensions
  • Multiple files with same name in same second
  • Files with multiple dots in name
  • Long filenames
  • Existing two-button modal usage (unarchive operations)

All scenarios handled correctly with proper unique name generation and user feedback.

ggfevans and others added 5 commits October 15, 2025 00:10
- Extend SimpleArchiverPromptModal to support optional third button
- Add generateUniqueArchivePath helper for timestamp-based naming
- Update archiveFile to show Replace/Rename/Cancel for collisions
- Generate unique filenames using YYYYMMDD-HHMMSS format
- Handle edge cases: files without extensions, multiple renames per second
- Preserve both existing and new files when rename is chosen
- Maintain backward compatibility with two-button modal usage

Fixes mfarr#18
Resolves issue where unarchiving files from folders with leading zeros
(e.g., 00-inbox) incorrectly stripped the leading zero, causing files
to be restored to wrong locations (e.g., 0-inbox).

Root cause: Unarchive operation was not normalizing paths before passing
them to Obsidian's file management APIs, unlike the archive operation
which consistently normalized all paths.

Changes:
- Added normalizePath() to folder creation in moveFileOutOfArchive()
- Added normalizePath() to file rename in moveFileOutOfArchive()

This ensures consistent path handling between archive and unarchive
operations, preventing leading zeros from being stripped.

Fixes mfarr#15

Tested scenarios:
- Single leading zero (00-inbox, 01-projects)
- Multiple leading zeros (000-archive)
- Single zero folders (0-temp)
- Deeply nested numeric folders
- Regular folders (regression test)
- Add smart merge when archiving folders with existing destination
- Compare file contents before replacing (byte-level comparison)
- Skip identical files, replace only when content differs
- Track merge statistics (added, replaced, skipped, failed)
- Handle errors gracefully without stopping entire merge
- Only delete source folder when completely empty

Fixes mfarr#5
- Integrate folder merge functionality from main branch
- Combine rename option (files) with merge option (folders)
- Folders show Merge/Cancel prompt (2-button)
- Files show Replace/Rename/Cancel prompt (3-button)
- Fix success message to capture original filename before rename
- Both features now work together seamlessly
- Move originalName declaration outside try-catch for proper scope
- Ensure both success and error messages reference original filename
- Prevents confusion if file.name is mutated during error handling
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add rename option when archiving file with existing destination

1 participant