[HN Gopher] An implementation of the NTFS filesystem in a Rust c...
___________________________________________________________________
An implementation of the NTFS filesystem in a Rust crate
Author : olvy0
Score : 91 points
Date : 2023-10-26 20:24 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jandrese wrote:
| Before you get too excited it is read only.
| tibbydudeza wrote:
| Probably prudent - would not trust any implementation except
| native ones in Windows that does writes.
| naikrovek wrote:
| well, you should. write support for NTFS is supported by
| quite a few tools, now, including the Linux Kernel.
| brucethemoose2 wrote:
| And I've had the new linux NTFS driver corrupt files more
| than once.
|
| In fact, it just corrupted the partition table of my
| external backup drive this year. Which was _last_ time I
| trusted it for anything but read-only mounting.
| helf wrote:
| and on the flip side I have been doing r/w to NTFS from
| linux for yeeeeears with never an issue.
|
| And I have had /windows/ corrupt NTFS volumes.
|
| Personal anecdotes rock :D
| naikrovek wrote:
| I've used it extensively on multiple machines and have
| had no problems. - \ _ ( tsu ) _ / -
| rerdavies wrote:
| Why is this even an answer? - \ _ ( tsu ) _ / -
| amno wrote:
| It have corrupted my drive several times.
| adzm wrote:
| This is pretty great. I've been wanting to make a simple utility
| that can scan an NTFS drive for a filename pattern; scanning the
| MFT is incredibly fast versus using the actual filesystem API
| calls to do so.
| gregschlom wrote:
| Sounds exactly like Everything (https://www.voidtools.com/) -
| do check it out if you're not aware of this tool.
| nfriedly wrote:
| Looks like it's read-only at the moment, but still pretty cool.
|
| It's dual-licensed as MIT or Apache 2.0, so it ought to be usable
| just about anywhere.
| msla wrote:
| > Looks like it's read-only at the moment, but still pretty
| cool.
|
| That's how Linux NTFS support started out, too.
|
| What is it about NTFS that makes writing hugely more difficult
| than reading?
| codetrotter wrote:
| It's probably mostly done out of carefulness. I'd do the same
| if I were to write my own implementation of a file system.
|
| Bugs and mistakes in the code are already not great when
| implementing the read part. But if you mess up the writing
| well now you're gonna cause corruption of existing data. No
| one likes that :)
|
| Better to stick to just reading for a long while, and weed
| out most of the bugs and getting an even deeper understanding
| of the filesystem, before starting the implementation of
| anything that will modify the data.
| nineteen999 wrote:
| > I'd do the same if I were to write my own implementation
| of a file system.
|
| Exactly. I have my own ext2 driver for a couple of hobby OS
| projects where the read side is extremely stable, but as
| the write side involves inode allocation, block/bitmap
| allocation etc. I don't turn it on on outside of testing
| since I know it's going to destroy the disk images until I
| "get it right".
| Diggsey wrote:
| I would expect writing to be much harder on all file-systems.
| There's only one way to read the data, but there could be any
| number of strategies for deciding where to write new data.
| pengaru wrote:
| Reading is _always_ easier to implement than writing. Only
| writing has the potential to actively corrupt the filesystem
| or leave it in some inconsistent state.
|
| Generally, the more modern the filesystem, the more
| complicated writing becomes.
| lights0123 wrote:
| That's the Rust standard--Apache 2.0 for its patent license,
| and MIT for its GPL-2.0-only compatibility.
| andy_xor_andrew wrote:
| Question for the experts!
|
| Has NTFS changed much in... 20 years?
|
| Linux filesystems seem to be evolving all the time (try to
| install any new distro today and check out how many filesystems
| you can pick from the dropdown...)
|
| Apple replaced one filesystem with another in just the past few
| years, with apparently some very advanced new features.
|
| But NTFS is just... NTFS? Does NTFS today look anything like how
| it looked in 1994? Or 2018? Does it change radically between
| versions of Windows? Or does the MS creed of compatibility at all
| costs mean it's basically a filesystem unchanged from the 90s?
| Thanks!
| MuffinFlavored wrote:
| > Linux filesystems seem to be evolving all the time (try to
| install any new distro today and check out how many filesystems
| you can pick from the dropdown...)
|
| This sounds like evolution of options more than evolution of
| existing file systems
|
| Is ext4 still not most popular for most end users? Curious how
| much ext4 has changed vs NTFS past... ~20 years (ext4 went
| stable 2008 apparently)
| Cu3PO42 wrote:
| ext4 remains the default for a lot of distros and probably
| most end users, but other options are common as well.
| openSUSE and Fedora now default to btrfs, RHEL defaults to
| XFS.
| loeg wrote:
| XFS also has not changed much in the past 10-20 years :-).
| yjftsjthsd-h wrote:
| https://en.wikipedia.org/wiki/XFS lists what I would call
| significant improvements, in particular,
|
| > Linux kernel 4.8 in August 2016 added a new feature,
| "reverse mapping". This is the foundation for a large set
| of planned features: snapshots, copy-on-write (COW) data,
| data deduplication, reflink copies, online data and
| metadata scrubbing, highly accurate reporting of data
| loss or bad sectors, and significantly improved
| reconstruction of damaged or corrupted filesystems. This
| work required changes to XFS's on-disk format.
| distract8901 wrote:
| My bet is that btrfs will replace ext4 in the nearish future.
| It's the default for Arch, which also comes default with
| filesystem snapshots before any system updates.
|
| It's pretty nice. I think it also supports some flavor of
| volumes or virtual partitions, but I don't have any real use
| for that kind of thing.
|
| The snapshots are really good though. Very fast and don't
| take up a ton of space, somehow.
| kcb wrote:
| Never using btrfs no matter how default it comes. Only
| filesystem I've had data loss with, 2 district occasions.
| toyg wrote:
| Btrfs seems to be the new standard, it might well end up
| being the one big thing Oracle did for Linux; it definitely
| evolved significantly over the last 15 years.
| naikrovek wrote:
| NTFS has gained support for a few features over the years, but
| it wasn't meant to evolve, much. Microsoft knew what they
| wanted from the filesystem and they wrote it to spec very early
| in its life.
|
| ReFS on Windows is where the changes are coming to. finally a
| 1st party filesystem which supports Copy on Write file cloning.
| a lot of core features of NTFS aren't supported on ReFS, so
| it's clearly not intended to be a replacement for NTFS.
| babypuncher wrote:
| Windows recently got support for booting from ReFS volumes,
| so it seems like Microsoft has started working on it again
| and maybe does think a move away from NTFS is possible in the
| future.
| mc32 wrote:
| There's ReFS for windows. Don't forget Apple was stuck with one
| barely functioning FS (HFS+) for decades.
| denkmoon wrote:
| Is ReFS real? Like does anyone really use it outside of
| Microsoft's labs?
| gecko wrote:
| It hasn't changed radically, but it _has_ changed. Wikipedia
| actually has a nice write-up if you want the details, but
| support for symbolic links, transactions, and partition
| resizing are all things that have materially improved my life
| in the last ~5-10 years.
___________________________________________________________________
(page generated 2023-10-26 23:01 UTC)