this post was submitted on 05 Dec 2025
83 points (100.0% liked)

Linux

10610 readers
619 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS
 

While NTFSPLUS continues to be developed as a new and modern NTFS open-source driver for Linux systems, at the moment NTFS3 from Paragon Software remains the most capable NTFS file-system driver within the mainline kernel. For the Linux 6.19 merge window a variety of fixes have landed for this driver.

While likely to not see too much use in practice, the NTFS3 driver with Linux 6.19 can now support timestamps prior to the year 1970. The first change noted for NTFS3 in the new kernel is pre-Epoch timestamps support for handling dates prior to the start of Unix time on 1 January 1970. NTFS3 had been relying on an unsigned 64-bit type but has now switched to a signed 64-bit type for coping with pre-epoch timestamps. The issue was raised by the xfstests program testing the file-system. But for anyone that may happen to have pre-1970 timestamps, Linux 6.19 fixes things up for NTFS3.

top 18 comments
sorted by: hot top controversial new old
[–] Feyd@programming.dev 26 points 1 week ago

Finally. This was what was keeping me from using ntfs on Linux

[–] illusionist@lemmy.zip 20 points 1 week ago (1 children)

The last time I had a time zone issue was tomorrow and I still can't figure out how I got there

[–] blx@piefed.zip 4 points 1 week ago

What's the weather like, down then? I've got plans for the weekend.

[–] the_riviera_kid@lemmy.world 15 points 1 week ago (2 children)

I cant imagine that being terribly useful but I'm sure now that I've said it some one will come up with a reason for why I'm wrong.

[–] fruitcantfly@programming.dev 32 points 1 week ago (1 children)

I set the timestamps of my music to its original release date, so that I can sort it chronologically... OK, I don't actually do that, but now I'm tempted

[–] jaybone@lemmy.zip 9 points 1 week ago

I was having an anxiety attack for a second.

[–] jaybone@lemmy.zip 5 points 1 week ago (1 children)

Seriously though, what are the most common use cases here?

[–] LeFantome@programming.dev 1 points 1 week ago (1 children)

Having the original UNIX source code with fully preserved timestamps?

[–] jaybone@lemmy.zip 1 points 1 week ago

Yeah I thought of something like that. Something you would pull off of an original tape archive. (An actual tar.) But then why would you put it on ntfs? 🤷

[–] bitcrafter@programming.dev 8 points 1 week ago

It may have taken a while, but the Year of the Linux Desktop has finally arrived in 1969!

[–] chrisbit@leminal.space 5 points 1 week ago (2 children)

Won't switching from an unsigned 64-bit integer to a signed one of the same size effectively halve how far into the future they can handle dates, exhausting it in 2038?

[–] FishFace@piefed.social 13 points 1 week ago (2 children)

The 2038 problem is from using a 32 bit int

[–] chrisbit@leminal.space 6 points 1 week ago (1 children)

You're right, I was thinking about 32-bit timestamps. Definitely not an issue for 64-bits.

[–] LeFantome@programming.dev 1 points 1 week ago (1 children)

Hundreds of billions of years should be sufficient t

[–] chrisbit@leminal.space 1 points 1 week ago

Won't somebody think of the Eloi?

[–] khleedril@cyberplace.social 2 points 1 week ago

@FishFace @chrisbit ... and halving the range of a 64-bit number effectively makes it 63-bit. That will give us plenty of time still!

[–] jaybone@lemmy.zip 2 points 1 week ago

You only need one sign bit right? So I think you are only losing 1 bit. Not 32.

[–] fruitycoder@sh.itjust.works 4 points 1 week ago

Very cool for archival work!