FR: Set created property to current date about obsidian-linter HOT 17 OPEN

@claremacrae I haven't tagged Peter in on this reply because it seems he already understands all of this and I don't want to eat up his time unnecessarily.

I don't think the proposed ticket is as insidious as you imply. Hopefully this summary can help crystalise things. I'm open to corrections:

• Linter offers a feature (created) and, under some conditions, it doesn't work as intended.
• Submitting tickets like this help to make amazing software like Linter even better.
• Obsidian won't fix the issue you linked because it can't be fixed.
• Linter, however, can be improved when the limitation on birthtime is understood.
• There is a potential solution for Linter here, but there is no solution to the linked and unrelated Obsidan issue.
• There are no extra paths and branches in the plugin for Electron and Mobile because attrs come from the Obsidian API.

As Peter noted earlier:

The Linter uses whatever Obsidian exposes, so they handle the created at and modified at values. So I can really only pull them and add that. Handling this scenario sounds feasible.

The exact line of code in Linter looks like this:

const createdAt = file ? moment(file.stat.ctime): moment()

My bet is that file.stat.ctime returns a zero value which is easily tested for. A potential minimal improvement might look like this, depending on coding standards:

const createdAt = file ? (file.stat.ctime !== 0 ? moment(file.stat.ctime) : moment()) : moment();

There are no platform-dependent branches, and maybe one extra simple test case required. Peter's insider knowledge and wisdom will be needed to see how such a change would shake out in the broader scheme of things.

We are in agreement, that it is up to the amazing Linter volunteers like Peter to triage. And I am here to offer Peter as much support as possible.

from obsidian-linter.

Hey @dudeskeeroo , could you add some context around which OS is using btrfs? I am seeing that some Linux distros do and wanted to make sure that I am not missing anything here.

from obsidian-linter.

G'day @pjkaufman, btrfs is the default FS on Fedora (since 2020), openSUSE (since 2014), as well as many minor and derivative distros.

It's also a commonly used install target for Debian/Ubuntu installations.

I'm using bttrfs on Ubuntu.

As an extra note, which I may have some details slightly off, I believe ZFS filesystem captures crtime but not using standard file attrs; you need to use the ZFS tooling to discover it. I'm assuming the created function of linter will also assume epoch time and result in 1970-01-01 for ZFS.

from obsidian-linter.

The Linter uses whatever Obsidian exposes, so they handle the created at and modified at values. So I can really only pull them and add that.

Handling this scenario sounds feasible.

from obsidian-linter.

Fantastic!

I wouldn't really expect you to start adding in FS specific implementations, especially if they require third-party libs and tooling. What a nightmare!

But changing a 1970-01-01 to the current date is a solution that would resolve the problem at hand (especially considering MD wasn't invented for another 34+ years ... virtually zero chance of a race condition!)

Thank you!

from obsidian-linter.

That 1970 date means no date. Not all systems provide ctime and mtime info, from what I’ve seen in many past discussions including on Obsidian Discord plugin-dev channel.

from obsidian-linter.

Hey @dudeskeeroo . Could you open a file explorer and check file properties for the files in question to see if it has a created date listed there?

Could you also run the stat command on the file as well and include the results here?

This will help me determine where the issue seems to be.

from obsidian-linter.

Sure thing ... I did explore all these options before making the ticket and probably should have included them in the initial ticket.

Explorer info:

stat yarn.lock:

  File: yarn.lock
  Size: 22618     	Blocks: 64         IO Block: 4096   regular file
Device: 57h/87d	Inode: 43642548    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/   zzz)   Gid: ( 1000/   zzz)
Access: 2024-01-20 10:41:36.012835726 +1000
Modify: 2023-03-11 13:23:40.730113285 +1000
Change: 2023-03-11 13:23:40.730113285 +1000
 Birth: -

And bonus getfattr -n user.birthname yarn.lock

yarn.lock: user.birthtime: No such attribute

I get similar results as above with a broad sampling of files on multiple btrfs subvolumes.

When running stat on a file in different FS type I get the birth (which shows it isn't an overarching system issue):

  File: /tmp/deleteme
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 1dh/29d	Inode: 15077620    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/   zzz)   Gid: ( 1000/   zzz)
Access: 2024-01-20 11:10:29.307138461 +1000
Modify: 2024-01-20 11:10:29.307138461 +1000
Change: 2024-01-20 11:10:29.307138461 +1000
 Birth: 2024-01-20 11:10:29.307138461 +1000

I've also tried various mount options for the btrfs subvolumes but none of them yielded a crtime.

from obsidian-linter.

Gotcha. So this would need to be handled by the Linter then since Obsidian would have no way of knowing what to do here.

from obsidian-linter.

For sure. I think it's safe to assume a crdate of 1970-01-01 is not a genuine note create time and using the current time is a more accurate assumption for a crdate.

I really appreciate you looking into this!

from obsidian-linter.

Gotcha. So this would need to be handled by the Linter then since Obsidian would have no way of knowing what to do here.

Not that it matters, but I’m confused by what you said. What have you seen in that info to think that about Obsidian?

from obsidian-linter.

@claremacrae I'll have a go at this, but @pjkaufman will probably be able to answer with more authority. I believe the linter plugin relies on file metadata to come from Obsidian, and Obsidian gets that information from the OS. With the brfs filesystem, the file birth time is not set and the OS returns a zero for the timestamp, which equates to the unix epoch 1970-01-01. Obsidian can't make any assumptions on what the file's birth time is ... it rightly hands back the zero when the attribute is requested.

I'm hoping that linter can make the assumptions Obsidian is incapable of, because there is some context around what linter is intending to do when inserting a created property. ;)

from obsidian-linter.

Thank you. I have never heard of birth time, only created time.

Wow.

I’m 100% confident that if a filesystem or OS does not report the creation time of a file, it is not the job of Obsidian or its plugins to fix that, though.

from obsidian-linter.

The Linter would not touch the file system. But it may be able to treat that timestamp as 0 and use the current time instead.

from obsidian-linter.

@claremacrae It gets a little confusing because there's ctime, crtime and birthtime. I may have this wrong, but I'll try my best below:

ctime is when a file was last modified (change time)

crtime is when a file was created on a filesystem (create time)

birthtime is when a file was first created on its original filesystem.

crtime and birthtime may not always be preserved, and as it turns out, be supported at all on some filesystems!

I'm going to assume Obsidian uses the Node fs.stat() call, which has a .birthtime field in the returned structure. There is no .crtime field from what I can tell.

As @pjkaufman stated, Linter wouldn't touch the FS or try to fix the underlying issue. But it can interpret the missing data better.

The Linter plugin has an intention to provide a created field in the YAML frontmatter when configured to do so. Setting a created field to 1970-01-01 (because fs.stat() returned zero or undefined birthtime) will invariably be incorrect when measured against the intention of the feature. Setting it to the current time is going to get it right more often than 1970, especially considering the markdown format wasn't invented until 35 years after the Unix epoch. ;)

Poor @pjkaufman has to figure out if Linter being run on existing file sets should set the created property to 1970, or use the current time, which will also be wrong for previously created/long-lived notes. It will definitely be the correct thing to do for new files. I imagine a config option to opt-in to defaulting created to current time when birthtime is unavailable would solve the issue, as it gives people visibility of the problem.

This issue shouldn't affect Windows/Mac users (unless they're using FAT filesystems or older HFS). I'm not sure how it affects users using the Obsidian Sync features across platforms.

from obsidian-linter.

Obsidian does not use Node on mobile.

There are already topics on the Forum where the Obsidian team instructs users on systems that do not provide ctime - and the recommendation is for users to modify their template, to add that info to the front matter at the point of creation...

I can't find the one I saw recently with that advice - although this shows that Obsidian is not intending to work on this feature.
https://forum.obsidian.md/t/bug-obsidian-on-linux-doesnt-show-correct-created-at-file-timestamp/62564

Poor @pjkaufman has to figure out if Linter being run on existing file sets should set the created property to 1970, or use the current time, which will also be wrong for previously created/long-lived notes.

Well that's a matter of opinion, for him to decide if it is worth his spending valuable, finite, volunteer time to help out users on systems that do not provide this functionality.

Another option of course is that if the time comes back as 1970, to do nothing, and not save it.

I imagine a config option to opt-in

Yeah, but that is yet more work to write, to document, and to maintain forever more...

If it were my project, I personally would say that if the user is running on a system that does not provide the facilities that Obsidian offers, it is not the job of potentially multiple plugin authors to work around it. It's just not a good use of volunteer time on free software.

from obsidian-linter.

Obsidian does not use Node on mobile.

… so writing code that uses Node on desktop and something else on mobile adds complexity to the code for current and future maintainers, and adds an additional fork in the testing requirements - behaviour with two different dependencies needs to be tested.

from obsidian-linter.