Announcement

Collapse
No announcement yet.

Paragon Sends Out Latest NTFS Read-Write Linux Driver Patches

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

  • SteamPunker
    replied
    Originally posted by birdie View Post
    Case sensitivity is a useless concept which only leads to the user confusion. I've been asking for years to name a single use case for it and no one has ever provided anything even remotely plausible.
    I wholeheartedly agree. Case-sensitivity is one of the few things that UNIX got wrong and Windows got right. Yes, technically lower-case letters and upper-case letters are different characters as far as the computer is concerned, but why should we as human beings have to adapt to the computer instead of vice versa? The computer doesn't care, so let's program it to be smart enough about it.

    And like you said, there isn't a single use case for it. I can't even think of any contrived theoretical ones. Case-sensitivity is confusing and it potentially causes errors. Case-preserving file systems are the best way to go, since they are the most intuitive, and still give the users the freedom to capitalize letters in file names as they see fit.

    By the way, I remember reading somewhere that NTFS is technically actually case-sensitive, but Windows itself enforces case-insensitivity and case preservation at a higher layer.

    Leave a comment:


  • birdie
    replied
    Originally posted by AndyChow View Post
    I hope this fixes some current issues with NTFS. Namely with ntfs-3g, I find transfering file from linux to such a drive seems to work fine and have the new data, but often I don't see it connecting the drive to windows. I have to run the repair drive from windows in order to see those files appear.

    Even with perfect integration of a native driver, I wouldn't use NTFS for any reason but compatibility. NTFS is far from perfect. There is no checksum functionality, not even for metadata. That right there makes it a non-starter except for unimportant data. Case-sensitivity is optional, which is a disaster waiting to happen. Compression is available but no choice of compression method. Forget ZSTD, Supported algorithms are: XPRESS4K or LZX (LZX available manually). Nothing close to even LZO. I'd like to see comparisons between XPRESS4K and ZLIB.

    Has any audit been done on the NTFS encryption thing?
    NTFS allows to easily implement that via extended attributes.

    Case sensitivity is a useless concept which only leads to the user confusion. I've been asking for years to name a single use case for it and no one has ever provided anything even remotely plausible.

    No choice of compression? compact.exe allows to specify XPRESS4K, XPRESS8K, XPRESS16K, LZX and classic modes. Microsoft's own website sucks ass - I had to install Windows 10 in a VM to get compact.exe help.

    Code:
    compact /?
    Displays or alters the compression of files on NTFS partitions.
    
    COMPACT [/C | /U] [/S[:dir]] [/A] [/I] [/F] [/Q] [/EXE[:algorithm]]
            [/CompactOs[:option] [/WinDir:dir]] [filename [...]]
    
      /C         Compresses the specified files.  Directories will be marked
                 so that files added afterward will be compressed unless /EXE
                 is specified.
      /U         Uncompresses the specified files.  Directories will be marked
                 so that files added afterward will not be compressed.  If
                 /EXE is specified, only files compressed as executables will
                 be uncompressed; if this is omitted, only NTFS compressed
                 files will be uncompressed.
      /S         Performs the specified operation on files in the given
                 directory and all subdirectories.  Default "dir" is the
                 current directory.
      /A         Displays files with the hidden or system attributes.  These
                 files are omitted by default.
      /I         Continues performing the specified operation even after errors
                 have occurred.  By default, COMPACT stops when an error is
                 encountered.
      /F         Forces the compress operation on all specified files, even
                 those which are already compressed.  Already-compressed files
                 are skipped by default.
      /Q         Reports only the most essential information.
      /EXE       Use compression optimized for executable files which are read
                 frequently and not modified.  Supported algorithms are:
                 XPRESS4K  (fastest) (default)
                 XPRESS8K
                 XPRESS16K
                 LZX       (most compact)
      /CompactOs Set or query the system's compression state.  Supported options are:
                 query  - Query the system's Compact state.
                 always - Compress all OS binaries and set the system state to Compact
                          which remains unless administrator changes it.
                 never  - Uncompress all OS binaries and set the system state to non
                          Compact which remains unless administrator changes it.
      /WinDir    Used with /CompactOs:query, when querying the offline OS. Specifies
                 the directory where Windows is installed.
      filename   Specifies a pattern, file, or directory.
    
      Used without parameters, COMPACT displays the compression state of
      the current directory and any files it contains. You may use multiple
      filenames and wildcards.  You must put spaces between multiple
      parameters.
    Last edited by birdie; 11 October 2020, 10:16 AM.

    Leave a comment:


  • SteamPunker
    replied
    I'm sure the ReactOS developers will be interested in this code as well. Kudos to Paragon for releasing it as open source, now that they no longer have a commercial need for it. NTFS compatibility is still important and useful for many people.

    Leave a comment:


  • AndyChow
    replied
    I hope this fixes some current issues with NTFS. Namely with ntfs-3g, I find transfering file from linux to such a drive seems to work fine and have the new data, but often I don't see it connecting the drive to windows. I have to run the repair drive from windows in order to see those files appear.

    Even with perfect integration of a native driver, I wouldn't use NTFS for any reason but compatibility. NTFS is far from perfect. There is no checksum functionality, not even for metadata. That right there makes it a non-starter except for unimportant data. Case-sensitivity is optional, which is a disaster waiting to happen. Compression is available but no choice of compression method. Forget ZSTD, Supported algorithms are: XPRESS4K or LZX (LZX available manually). Nothing close to even LZO. I'd like to see comparisons between XPRESS4K and ZLIB.

    Has any audit been done on the NTFS encryption thing?

    Leave a comment:


  • jacob
    replied
    Originally posted by uid313 View Post

    I don't really know the difference. I just know r=read, w=write, x=execute, and there are 3 sets of them for user, group and world. Then I don't know how NTFS works. I don't know why the POSIX one is bad, or why the Windows one is good.
    For one thing, the POSIX model only allows read, write and execute. It can't distinguish between allowing a user to overwrite a file or simply appending to a file (important for log files in particular), it provides no permissions for manipulating attributes or making changes to the permissions themselves, renaming a file, or other permissions that may not apply to files but are meaningful for other objects (be able to bind a socket to a port, for example, or tracing permissions on a process etc.) One of my pet peeves in POSIX is that by default there is no permissions to delete a file. It's handled by write permissions to the containing directory, which means that if you can create a file somewhere, then by the same token you can also delete any file in that same dir (including files you don't own), which is utter madness. In Linux some of these issues are handled by additional attr flags, but those are not part of the permissions, can't be set separately for users, groups etc and are lost in any tool that only preserves permissions and not other attributes.

    Then as you say, POSIX only handles the user, one single group and the world. It can't set various permissions discretely for multiple individual users or groups. This is called ACLs (Access Control Lists) and Linux supports it but the way it's implemented makes it a huge pain to use, it's still limited to the r/w/x model and it can only apply to actual files, not to other types of file descriptors.

    Leave a comment:


  • onlyLinuxLuvUBack
    replied
    Originally posted by gojul View Post

    NTFS permissions are much more fine-grained than POSIX permissions, and they go far beyond setfacl abilities. However NTFS performance is not exactly... good : http://blog.zorinaq.com/i-contribute...an-other-oper/ - thus relying on a proprietary file system may not be the best thing to do.
    A phoronix shootout benchmark with Linux+root=ntfs vs Linux+root=ext4 would solve this.

    Leave a comment:


  • Nth_man
    replied
    Originally posted by uid313 View Post

    I don't really know the difference. I just know r=read, w=write, x=execute, and there are 3 sets of them for user, group and world. Then I don't know how NTFS works. I don't know why the POSIX one is bad, or why the Windows one is good.
    Linux-Unix "user-group-other" permissions have the advantage that they are clearly auditable (and easily understandable). For example, when you see the permissions of a file... you quickly know who can read it (unlike what happens with ACLs, where you have to see the inheritances of the previous folders, the exclusions, the changes that will be inherited, the changes which will be not inherited, etc. --and many previous folders can exist). Having difficulties knowing who can read a file ends up causing serious troubles (sometimes legal ones).

    When creating users of the same kind: in some cases it's better to use an auxiliary script e.g. in order to add each user to some groups. That script also comes in handy for automating other jobs that have to be done when creating a user (even if ACLs are used).
    Last edited by Nth_man; 11 October 2020, 04:11 AM.

    Leave a comment:


  • gojul
    replied
    Originally posted by uid313 View Post

    I don't really know the difference. I just know r=read, w=write, x=execute, and there are 3 sets of them for user, group and world. Then I don't know how NTFS works. I don't know why the POSIX one is bad, or why the Windows one is good.
    NTFS permissions are much more fine-grained than POSIX permissions, and they go far beyond setfacl abilities. However NTFS performance is not exactly... good : http://blog.zorinaq.com/i-contribute...an-other-oper/ - thus relying on a proprietary file system may not be the best thing to do.

    Leave a comment:


  • uid313
    replied
    Originally posted by jacob View Post

    But the POSIX rwxrwxrwx model is brain dead anyway, U would much prefer Linux to ditch it for pervasive ACLs like Windows (the semi-POSIX ACLs supported by Linux are a joke).
    I don't really know the difference. I just know r=read, w=write, x=execute, and there are 3 sets of them for user, group and world. Then I don't know how NTFS works. I don't know why the POSIX one is bad, or why the Windows one is good.

    Leave a comment:


  • ypnos
    replied
    Originally posted by darkbasic View Post
    I still don't understand what would have been the advantage to write it as a userspace driver: maybe the fear to not get it merged?
    1. Barrier to entry -- you don't have to learn kernel interfaces and general kernel programming, just the FUSE API
    2. Easier debugging in userspace
    3. More resilient, bugs in the unpriviledged FUSE driver should not be able to crash the kernel
    4. Easier deployment, no need to migrate to every new kernel version
    5. Cross-platform support, as FUSE is not bound to Linux

    Leave a comment:

Working...
X