#1

Use case or problem

Sorry if there is already a solution for this. I couldn’t find it.

Currently, sorting by Created time only works for as long as you never move notes to another filesystem or have to restore from a backup. Any user who implements a note taking system that relies on this type of sorting will be in trouble eventually.

This is because there is no practical way to restore filesystem-level creation times (which Obsidian seems to use) on copy/restore. Or it may be possible on some filesystems, but not on others, like ext4.

In other words, a note’s logical creation date is not generally equivalent to the creation date of the file that contains the note, so you could argue that sorting option provided by the app cannot work correctly based on just the filesystem metadata.

Proposed solution

When determining a note’s creation timestamp for sorting purposes, prefer a dedicated metadata field in the front matter, if present, and fall back to the filesystem metadata otherwise.
This way we could at least write a script to update the front matter before running a backup or a migration.

Current workaround (optional)

1 Like
Preserve Creation Dates when Using Obsidian Sync
#2

You can partially achieve this, the part about saving the timestamp in the YAML, using Templater which is available in the Community Plugins. With it you can set a default template for new files and add the date/time in there. For example, this is what my default template looks like,

---
aliases: [""]
tags: []
dateCreated: <% tp.file.creation_date('YYYY-MM-DDTHH:mm') %>
---
#3

It’s a nice way to set metadata automatically, but will Obsidian use this date for sorting? If not, then it doesn’t solve the issue, unfortunately.

#4

Unfortunately no, not yet. Hence, the partial solution. It might still be useful to do this so that if Obsidian implements it (or some plug-in does), our notes would have the data already to work with.

#5

I might have come up with a new workaround.

Keep the notes directory in a dedicated partition, which is backed up by taking filesystem snapshots.

Making and restoring such a backup is more complicated, but it should theoretically preserve all metadata and there will be no need to bother with front matter timestamps.

#6

Curious as to the need for a separate partition for text files! After my last post, I went and checked some of my old notes and I couldn’t find any notes changing their creation times accidentally. I do support the FR for more options for creation metadata but I think you might be encountering a bug perhaps.

#7

The point of a partition is to be able to restore it without modifying file metadata.

I don’t know what filesystem you use, but in Linux (ext4) you can break the creation date by simply moving a file to another drive and back with no way to recover the original date.

#8

Interesting. I am on a Mac and didn’t know that. I just read about it and turns out Windows (and Linux from your experience) treat time as file-system centric so whenever a file enters the file-system, it gets that time whereas Macs treat time as document-centric so it is preserved when you move files around.

#9

Yes, this is the problem. In particular when moving between partitions / filesystems. When moving within a single partition, the dates are actually preserved.

#10

So I learned something today!

As a workaround, perhaps, you can use cp -a src dest or just cp -p src dest to copy in the terminal.

#11

That doesn’t work. When I say setting the creation date is impossible, I mean it’s literally impossible, as in, no matter what you do.

By the way that was a surprise for me as well.

#12

I am not speaking of setting the creation time. The command is to copy file(s) while preserving their existing creation time.

   -p     same as --preserve=mode,ownership,timestamps

   --preserve[=ATTR_LIST]
          preserve the specified attributes (default:
          mode,ownership,timestamps), if possible additional
          attributes: context, links, xattr, all

From the man page for cp.

#13

I understand. But cp doesn’t preserve the creation time for exactly the same reason it’s not possible to set it. The -p flag doesn’t do it on Linux.

There is nothing in the man page about the creation time specifically. Other timestamps do get preserved with -p.

#14

Oh man. Sorry.

#15

Looks like I have solved this problem for myself as follows.

  • Resize the existing partition containing markdown notes to 2Gb to keep backups small.
  • Move everything else from the /home/user directory to a new partition
  • Mount the 2Gb notes partition on top of the /home/user
  • Create backups of the notes partition using using ddrescue

It took some work, but ultimately this approach might even be superior as I won’t need to worry about managing the dates in text.

#16

Great!

Perhaps, you could share your solution in this Linux issues thread so others with similar issues could also benefit.

#17

Hi, just wanted to point out that there is another use case which pretty much requires the use of a creation date in frontmatter, namely importing notes from other systems.

It would be really great if Obsidian supported the use of a standard created frontmatter variable.

1 Like