Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by mozo View Post
    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..
    Last edited by oiaohm; 16 November 2021, 07:53 PM.

    Leave a comment:


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

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mozo View Post
    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..

    Originally posted by mozo View Post
    That's not a problem at all:
    Code:
    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.
    Code:
    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.

    Leave a comment:


  • mozo
    replied
    Originally posted by oiaohm View Post
    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.


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


    Originally posted by oiaohm View Post
    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:
    Code:
    x-systemd.device-timeout=10

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Zeioth View Post
    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.

    Originally posted by mozo View Post
    Yep it is
    https://wiki.winehq.org/FAQ#Does_Win...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.

    Leave a comment:


  • mozo
    replied
    Originally posted by Zeioth View Post

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

    Leave a comment:


  • Zeioth
    replied
    Originally posted by mozo View Post

    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.

    Leave a comment:


  • deadite66
    replied
    tried ntfs3 on rc6 and rc7 ended up with a corrupted folder shortly after and had to fix it in windows, so going to be a while before its usable.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Vaporeon View Post
    From a quick glance at the driver it appears it supports regular permissions by storing them the same way Windows does for the Windows subsystem for Linux.
    There should be no reason it can't be used as your rootfs if you really want to use it that way.
    There is a reason why you should not. Microsoft with WSL2 goes to a ext4 partition as one of the reasons is the unsolvable incompatible between Linux permissions and Windows permissions. The reality here you cannot store LInux style permissions correctly in NTFS. This comes more of a problem when you start using Linux security modules as well. Lack of permissions or incorrect permissions on a transfer drive of some form is not a problem as your OS partition having lack of permissions or incorrect permissions.

    Leave a comment:


  • Vaporeon
    replied
    Originally posted by ruthan View Post
    When it would be able to boot Linux form NTFS partition to get rid of Linux specific filesystems? NTFS would be nice for multiboot.
    From a quick glance at the driver it appears it supports regular permissions by storing them the same way Windows does for the Windows subsystem for Linux.
    There should be no reason it can't be used as your rootfs if you really want to use it that way.

    Leave a comment:

Working...
X