Announcement

Collapse
No announcement yet.

The New NTFS Driver Looks Like It Will Finally Be Ready With Linux 5.15

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

  • #21
    This is great news.

    And on exFAT, I'm using it between Linux and Windows, but damn Android has to do weird shit and ONLY allows storage it has formatted itself? Why can't phones be normal...

    Comment


    • #22
      CommunityMember birdie stormcrow Nille : Thanks for your informative responses!
      Last edited by pipe13; 31 July 2021, 04:08 PM.

      Comment


      • #23
        Originally posted by xeekei View Post
        but damn Android has to do weird shit and ONLY allows storage it has formatted itself? Why can't phones be normal...
        It depends on the manufacturer. I used Motorola and Samsung so fair and they where perfectly fine with all filesystems that i give them. the older devices didnt like the exfat but the devices didnt support sdxc on paper.

        Comment


        • #24
          Originally posted by birdie View Post

          exFAT is (good) for removable storage and file archiving. It can't and won't work for storing anything which requires MAC, so NTFS is as relevant as ever.
          exFAT is lousy for file archiving.

          The problem is that ext(x) filesystems allow any character in a filename except for NULL and forward slash, which is a superset of the allowed characters in the exFAT definition:



          For example: Asterisk; Less-than sign; Greater-than sign; Colon; Question mark; Vertical bar; and Back slash are not allowed in exFAT filenames (plus sundry control codes)

          I've been caught out by this and had to rename a non-trivial number of files.

          Similar restrictions apply to NTFS: https://docs.microsoft.com/en-us/win.../naming-a-file - note that if NTFS uses the POSIX namespace any Unicode character except / and Null are is allowed. Note that the POSIX standard for portable filenames is considerably more restrictive.

          Non-Microsoft drivers can put non-standard characters in filenames used in exFAT, but obviously this will generate undefined behaviour if accessed by a Microsoft driver, or one written to abide by the Microsoft specification.

          I'm not going to hold up the relatively liberal approach of many Linux filesystems towards filename standards as being perfect. It is subject to well argued criticisms: https://dwheeler.com/essays/fixing-u...filenames.html

          I'm still looking for a good cross-platform approach for file archiving. exFAT isn't the solution, and neither, unfortunately, is UDF (in any of its revisions), which is a shame.

          Comment


          • #25
            Finally. It took a long time to mainline it.

            Comment


            • #26
              Originally posted by jarekZ View Post

              maybe NTFS is losing its popularity among the device manufacturers so it was not so profitable for paragon to continue selling this driver as a proprietary product. On other hand, they're getting a lot of (good) PR from this story. Also, looks like the person sending these patches isn't just a developer, but an owner of this company. So he's doing it simply because he can, why not?
              I think it had a lot more to do with exFAT, so Paragon went FU to MS.

              Last edited by Slartifartblast; 31 July 2021, 05:52 PM.

              Comment


              • #27
                Sad to see the code GPLv2 with all the *BSD projects wanting to avoid any new GPL encumbered code. When I migrated some data on an external hard drive to FreeBSD 12.x a couple years back it was really hard because it was ExFat formatted. EXT4, NTFS, ExFAT- all are undersupported on OpenBSD and FreeBSD and I assume the other two big *BSDs as well. Whenever I post about the lack of a cross platform FS for the *BSDs people are quick to point out the Universal Disk format UDF but that lacks write support in some of the *BSDs. Even their own UFS/FFS implementations between say OpenBSD and FreeBSD aren't compatible and can result in corruption. It is hard to share files between Windows, Linux, and Open and FreeBSD.

                Comment


                • #28
                  Originally posted by kbios View Post
                  The data=journal mode absolutely protects from data loss
                  No, it absolutely does not.

                  Hopefully you have a good backup policy despite your confusion, right?

                  Alternatively, can I interest you in this bridge I have for sale? :P

                  Comment


                  • #29
                    Originally posted by kylew77 View Post
                    Sad to see the code GPLv2 with all the *BSD projects wanting to avoid any new GPL encumbered code. When I migrated some data on an external hard drive to FreeBSD 12.x a couple years back it was really hard because it was ExFat formatted. EXT4, NTFS, ExFAT- all are undersupported on OpenBSD and FreeBSD and I assume the other two big *BSDs as well.
                    Do you perhaps see the connection there?

                    I admit, for a long time I preferred BSD's license over the more restrictive GPL, but having seen abuses like Android etc for years now I've been forced to lean more strongly to GPL instead. (Not that it helped in Android's case anyway, but...)

                    Comment


                    • #30
                      Okay. I've ordered the parts for a new build. First in ten years so I might be a bit stale. I'll need to pick some filesystems. The new machine will be 5950x and initially have a 2TB SDD plus 8TB rotating rust for backup and storage. I use rsnapshot for backup. Fedora is my daily driver. I'm open to suggestions, but I'm thinking
                      /dev/sda:
                      1MB grub2
                      256MB UEFI fat16 or exFAT WHICH???
                      2GB boot
                      64GB ext4 Fedora
                      64GB ext4 CentOS9 when released
                      128GB linux swap
                      1.74TB <rest>

                      /dev/sdb:
                      Backup, remote sensing images, and old project dirs I don't use much but don't want to lose.

                      ...where <rest> is TBD Real Soon. My current system is a 2500k SNB. VMs work, but they don't work real well. So I multiboot a raft of distros that will go into VMs on the new build. On my current system <rest> is just a single ext4 partition where I place a shared /home and maybe a few other things. But the new system will be with me a while, and might do with something else. ext4 under lvm, btrfs, and xfs are the likely suspects, as they work well and are popular with the RedHats. NFS is a likely requirement, as I'll eventually need to install a Windows VM and share files. This link says it's easy https://graspingtech.com/mount-nfs-share-windows-10/
                      ...but if any of you disagree I'd sure rather know now than later.

                      I'm thinking either LVM/ext4 or btrfs. Is there any (dis)advantage to putting btrfs under LVM? This isn't cast in concrete yet -- would I maybe be best off KIS and just use lvm/ext4? For simplicity I'll want to use the same configuration on the big slow sdb drive, and any other sdd's I might acquire.

                      I really need a refresher on btrfs and lvm. Please don't waste your life on it, but any quick suggestions will be appreciated. Thanks!

                      Comment

                      Working...
                      X