The New NTFS File-System Driver Has Been Submitted For Linux 5.15

[Zeioth]

What issue? I tried ten of thousands games on NTFS with Wine - no problems at all.

Well the issue itself is with the mounting system most distros use, not mounting ntfs partitions with the right permissions, provoking wine to fail when trying to create a wineprefix. Mounting the ntfs partition permanently using fstab has no issue at all.

[mozo]

Mounting the ntfs partition permanently using fstab has no issue at all.

Yep it is

[oiaohm]

Well the issue itself is with the mounting system most distros use, not mounting ntfs partitions with the right permissions, provoking wine to fail when trying to create a wineprefix. Mounting the ntfs partition permanently using fstab has no issue at all.

This is not the problem I was refering to.

Yep it is

https://wiki.winehq.org/FAQ#Does_Wine_run_on_all_Unix_filesystems.3F

Like ntfs3 at the time this was updated one of the noted missing feature is shared mmap write support. Yes that is something that has to come up from the file system driver to work right.

There are odd glitches that will get you at this stage still using ntfs3g or new ntfs feature in kernel. The feature wine users of a file system depend on what the program is doing at the time.

The reality if you hit a odd bug with game or program under wine the first thing you should do at this stage is reinstall that game on ext4, xfs or btrfs and see if the problem disappears. None of the ntfs mounting options with Linux are in fact 100 percent feature complete there are odd things like mmap features for files that don't work. The new ntfs driver in kernel is closer but its not complete.

Next problem you still do not have a chkdsk/repair tool that is designed to match up with the Linux file system drivers.

Thing to remember a Linux file system has to implement a min set of features to be usable at all. But file systems don't have to implement them all. Yes there are features that function when you use xfs that don't function when you use ext4 as well. Wine was attempted to be code file system neutral but it does expect at times broader features than what the min is.

Yes the mounting options don't fix the missing file system features that are optional in the Linux kernel. Quite a few of them have have to be supported by the file system driver.

Zeioth you have done a works for me and you have changed something that does not fix the core problem but it nicely adds another problem.

The lack of a proper repair tool permanently mounting in fstab if this means mounts on boot can be good way to lock you self out of you system when ntfs partition fails . So yes this is a different feature that is need a proper Linux repair tool. You should never permanently mount a file system in fstab that you don't have a functional fsck tool for. If you do you have just done a works for me that will cause you problems in future.

[mozo]

The reality if you hit a odd bug with game or program under wine the first thing you should do at this stage is reinstall that game on ext4, xfs or btrfs and see if the problem disappears.

Never have a single problem and I ried literally over 10K games.

Next problem you still do not have a chkdsk/repair tool that is designed to match up with the Linux file system drivers.

The lack of a proper repair tool permanently mounting in fstab if this means mounts on boot can be good way to lock you self out of you system when ntfs partition fails . So yes this is a different feature that is need a proper Linux repair tool. You should never permanently mount a file system in fstab that you don't have a functional fsck tool for. If you do you have just done a works for me that will cause you problems in future.

That's not a problem at all:

x-systemd.device-timeout=10

[oiaohm]

Never have a single problem and I ried literally over 10K games.

You would not have played though all 10K games. Like the mmap issue with sharing issue turns up in some cut senses in quite a few games not the game engine. So really simple to fool yourself into a works for me.

These issues can be why you get 90% though a game and your save file dies repeatedly at the same point of progress so unable to complete game until you put the game on ext4/xfs or btrfs and it functions correctly..

That's not a problem at all:

x-systemd.device-timeout=10

No that does not fix damaged file system mount. Remember the device as show up and is fine when the mount starts.

x-systemd.mount-timeout=

This exists for file system driver having a failure to mount due to damaged state or the like. So you only set 1 of the 2 required values but this has a problem.

There is a problem where is the option to limit the fsck time. systemd presumes you are mounting file systems with proper repair tools. so repair tools should be able to run.

The fun of a file system being flagged as damaged and the system attempt to repair it only to find out there is no functional fsck there is no proper flag in fstab for this problem.

[mozo]

Ofc it does not fix damaged file system but you can boot your system.

[oiaohm]

Ofc it does not fix damaged file system but you can boot your system.

That not a problem the flag you are using is meant to fix. x-systemd.device-timeout is how long systemd will wait for the device to appear before attempting mount.
x-systemd.mount-timeout= is how long it will wait in the mount process before aborting the mount. device-timeout is damaged device not damaged file system. mount-timeout can because of damaged file system.

Neither of these address how long systemd will wait attempting to fix a file system and it cannot because the tool is missing or a joke. repair tool missing/incomplete means you should not have a file system mounting as part of boot process. User mountable after system has come up is valid and will not result in you getting yourself locked out of your system.

mozo there is a reason why you can define a file system mount in fstab that does not mount on boot. One of the cases this is to handle is file systems that you don't have proper repair tools for that you will be using read/write. So that you can get into the system if something goes wrong..