NTFS3 Kernel Driver Sees Fixes Sent In For Linux 5.19

[You-]

Did the maintainer make any comment about their disappearance/unavailability at all?

Yes, he had replied a month ago to the original thread that raised concerns. He said they had continued work, still were working on a ntfs3-utils package and that developer had taken some time for a break after February or so.

[theriddick]

I've just been using winbtrfs on windows10 for my other drives so that means they work decently under Linux compared to having them remain NTFS. Additionally I can use zstd compression which is also well supported now.

The ONLY hickup I've had is some mods for games have case sensitive filenames going on even thought their not meant to (slack modders) and in turn errors happen.
BTRFS has no way to set case insensitivity as far as I can tell without going into FUSE virtual file system route (stuff that!)
EXT4 allows you to set case insensitivity on a per folder basis which is nice but that isn't really supported under Windows.

[TheDcoder]

Yes, he had replied a month ago to the original thread that raised concerns. He said they had continued work, still were working on a ntfs3-utils package and that developer had taken some time for a break after February or so.

Great, thanks for replying. Here is the original response from the developer for reference.

[oiaohm]

At least my second point stands, there's no API to set the birth time Or maybe it's also been tackled in the meantime?

That one turns out to be hell. Lot of the file system journals you know the bits that track reads/writers in case something goes wrong does in fact use the birth time/creation time of the file.

So creation date/birth date change in fact need to be a file system unique command in a lot of cases. This is why ext4 for changing a file creation time is by the debugfs and requires unmounting the file system. Yes unmounted the journal is resolved so now you can change a value without starting a conflict between journal data and inodes.

Also one of the fun ways to have ntfs and windows really ruin you day is to be restoring a backup that is changing lots of birth dates due to restoring files and have the ntfs file system journal of windows bit the dust so forcing you to start over. So even under windows playing with birth time is rolling a game of dice. This is most like the most dangerous file value to play with and its all due to those who wrote file system journals using it.

[sinepgib]

You- At least for KDE that's not the case though. When removing NTFS-3G from the system, Dolphin complains about not finding it, instead of just using NTFS3.

Is the module mounted? Maybe there's a udev rule missing to mount it? Just spitballing.

[sinepgib]

I've just been using winbtrfs on windows10 for my other drives so that means they work decently under Linux compared to having them remain NTFS. Additionally I can use zstd compression which is also well supported now.

The ONLY hickup I've had is some mods for games have case sensitive filenames going on even thought their not meant to (slack modders) and in turn errors happen.
BTRFS has no way to set case insensitivity as far as I can tell without going into FUSE virtual file system route (stuff that!)
EXT4 allows you to set case insensitivity on a per folder basis which is nice but that isn't really supported under Windows.

I was under the impression it supported it per-volume. It seems I was wrong, but this may be useful to you: https://www.spinics.net/lists/linux-...msg104554.html

[birdie]

That one turns out to be hell. Lot of the file system journals you know the bits that track reads/writers in case something goes wrong does in fact use the birth time/creation time of the file.

So creation date/birth date change in fact need to be a file system unique command in a lot of cases. This is why ext4 for changing a file creation time is by the debugfs and requires unmounting the file system. Yes unmounted the journal is resolved so now you can change a value without starting a conflict between journal data and inodes.

Also one of the fun ways to have ntfs and windows really ruin you day is to be restoring a backup that is changing lots of birth dates due to restoring files and have the ntfs file system journal of windows bit the dust so forcing you to start over. So even under windows playing with birth time is rolling a game of dice. This is most like the most dangerous file value to play with and its all due to those who wrote file system journals using it.

I've changed birth times of file on a mounted ext4 volume using debugfs a dozen times - it worked perfectly.

[intelfx]

Wow, interesting, great! Now I've not seen statx->stx_btime being implemented anywhere in Linux. Have you?

For all intents and purposes it's missing altogether. And kernel 4.11 was released 5 years ago.

$ stat /
File: /
Size: 208 Blocks: 0 IO Block: 4096 directory
Device: 0,52 Inode: 256 Links: 1
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-03-03 05:42:10.230919736 +0300
Modify: 2020-07-17 04:06:51.258578586 +0300
Change: 2022-01-09 14:05:59.390898093 +0300
Birth: 2020-07-24 08:20:57.152067453 +0300

Nuff said.

At least my second point stands, there's no API to set the birth time Or maybe it's also been tackled in the meantime?

You forgot to say why you think this API should exist.

[oiaohm]

I've changed birth times of file on a mounted ext4 volume using debugfs a dozen times - it worked perfectly.

This shows that you don't understand why its under debugfs. If you read the directions on that feature you would have found it meant to be done on a umount filesystem if possible or in a case you are not going to have a journal event as in a power outage or something causing a journal recovery because if it half way done things and go horrible wrong. Just because debugfs allows you todo something does not mean what you have done is safe.

Items that a not safe are left behind more complex interfaces so lower skilled people hopefully read the instructions before using. Of course you have been one of these underskilled for the feature who have not read the documentation about it and then stupid uses a works for me defence.

Not everything should be given a easy to use interface. Statx is fine you are only reading value. Changing value requires careful consideration on how safe this action is. Birth date/creation date is one of those things. Remember items like ext2 and ext3 never exposed to users the creation date even that they had it because it was internally used.

Most commerical unix file systems also had either birth date/creation date yet the means to read this value was not include in posix because if you had the means to read this value you would want to write to it right. And writing birth date/creation date has been risky with many file systems due to journal usage and other protection usages.

So this is really a harder problem. One of the fun one is where the birth date of the file happens to be salt value for the encryption of the file. If a API is every created to allow changing birth date/creation date of file it will have to have the option to straight up fail no matter what as some file systems changing that value is very hazard.

[JMB9]

Wow, interesting, great! Now I've not seen statx->stx_btime being implemented anywhere in Linux. Have you?
...

Seems to be implemented (for CLI) - but I wonder why so inconsitently:
ls -l -> mtime, i.e. last modification (the default for ls),
ls -lu -> atime, i.e. last access,
ls -lc -> ctime, i.e. last status change,
ls -l --time=birth -> btime, i.e. time of creation.

I would have thought that -lm, -la, -lc, -lb would be more consistent ... doesn't look nice in that state.
But at least it is possible ... and consistency could be reached by own aliases, if this would be useful.