The NTFS features we have chosen to not support in ReFS are: named streams, object IDs, short names, compression, file level encryption (EFS), user data transactions, sparse, hard-links, extended attributes, and quotas.
Of these, I'm sorry to see the demise of sparse files. This was, IMHO, the single most under-utilized feature of NTFS, and I was able to integrate support for sparse files into a number of clients' applications (I'm a low-level consultant and developer) to great effect. While the increasing size of volumes along with the sub-par utilization of this feature makes it an obvious victim when creating a new filesystem and looking for features to drop, sparse files can be amazing for other reasons.
One of the advantages of sparse files is that they can be used to naively support certain seek-related behaviors. If you create the file right, you can save yourself a lot of code and complexity in any applications consuming that data.
The biggest advantage of sparse files though is speed. For instance, you can create a container file of X size filled with zero bytes, and only use as much space as the end application requests (for example, creating a virtual disk of 2TB that only takes up 100MB on disk).
I think i'll miss hard links the most. I recently switched from linux to windows due to better display management and it seems that many programs fail at handling symlinks in a reasonable way, only hard links make them act rationally.
I was going to mention that in my comment, but I refrained for a number of reasons: a) old non-symlink-aware Windows software will treat symlinks as hardlinks (by and large), b) it's very possible that hardlinks will be present in ReFS in one form or the other as Microsoft has a long history of using a dozen different names and implementations to create hardlink-like behavior over the years, and c) the only apps that can mishandle symlinks are those that were written with symlink support in mind, but they mangled it and did a bad job pulling that off - which, while very much lamentable, cannot be blamed on MS.
Honestly, any serious application that doesn't take symlinks into account in 2010s is a joke. Unfortunately, in the Windows world, there's a lot of them. Even hard-core backup applications (I've consulted for a few backup companies) mess this one up.
Hardlinks were the precursor to softlinks, in this day and age their only purpose is to let you say "I've given up on the software I use handling soft links properly," and while we can wish for such a feature, I don't think it's that bad of a decision to drop them.
>Honestly, any serious application that doesn't take symlinks into account in 2010s is a joke.
I agree, but it doesn't stop me from having to use these programs where they clearly kill their competitors in terms of features or usability.
Not to start a fight but windows programs take a serious step back in ease of use (for me) vs their linux counterparts. I work from home so my home PC = my work PC.
Unfortunately I'm a massive fan of multiple displays (5 currently) in various orientations and linux epicly fails at this. I used linux as my primary OS for 7 years but finally gave up over this singular issue.
Softlinks aren't just a different version of hardlinks, they have totally separate semantics. Hardlinks allow you to link multiple files without worrying if the original is destroyed, softlinks link to a file location. Take backups for example, I can have versioned backups and hardlink identical files to a previous version. The advantage of hardlinks is that I can treat the backups as fully independent, and use them with any program. If I were to use softlinks, or even deltas, I would need to use the original software to delete, or even extract the contents. With hardlinks, I can delete and copy the backups with any application. (Rsync and time machine actually implement this mechanism).
I agree that it's a strange set of choices. Eliminating quotas and compression might be OK for something positioned as a basic filesystem, but for something billed as a "next generation" filesystem it seems odd. Eliminating extended attributes is an even bigger step backward, because they're such a useful building block for other OS features (e.g. look at their use to in Linux to support ACLs and security labels).
Failing to support sparse files, though . . . man, that's just insane. That would relegate ReFS to the status of a toy in most filesystem developers' minds, even before you consider their increasing usefulness when storing virtual-machine disk images in a shared filesystem to support migration, etc. It's hard to imagine that none of the many people who must be involved in this at MS raised the red flag. What seems more likely, from what I know of MS culture, is that some people did raise it but then some idiot dictator with a reputation built on some long-irrelevant project ignored or dismissed their objections.
I'm pretty sure Microsoft's VHD file format has built-in support for sparse volumes... maybe it was a case of since they didn't need it, they could trim everyone else's advantage.
Since ReFS doesn't look to be in the client version of Windows 8, though, i don't think it'll make much difference to applications - and i expect they'll add some of these features back before Windows 9. Hopefully they have a more transparent versioning system than NTFS this time around
If ReFS is really in the Server version of 8, and if it really doesn't support sparse files, consider the implication of built-in deduplication. It does sparse files at a layer above the filesystem, along with dedupe and compression. Or, as mappu points out, ReFS could assume it's running on VHD/CSV, punting those features to a lower level.
Perhaps Microsoft is making a decision to focus the filesystem on being a simple storage engine and moving features into other modules (primarily) above or even below it?
Dedup isn't quite the same as sparse files. If the filesystem is unaware of dedup, then it still has to allocate its own structures corresponding to the dedup'ed space, seeking to the next hole or next allocated block won't work (not that many applications are smart about holes or that MS didn't already suck in that area), etc. Dedup - even in its most absolutely simple form of just detecting zero blocks - does at least avoid the fatal problem of allocating actual disk space uselessly, but sparse files are still basically a filesystem problem and need to be treated as such.
Of these, I'm sorry to see the demise of sparse files. This was, IMHO, the single most under-utilized feature of NTFS, and I was able to integrate support for sparse files into a number of clients' applications (I'm a low-level consultant and developer) to great effect. While the increasing size of volumes along with the sub-par utilization of this feature makes it an obvious victim when creating a new filesystem and looking for features to drop, sparse files can be amazing for other reasons.
One of the advantages of sparse files is that they can be used to naively support certain seek-related behaviors. If you create the file right, you can save yourself a lot of code and complexity in any applications consuming that data.
The biggest advantage of sparse files though is speed. For instance, you can create a container file of X size filled with zero bytes, and only use as much space as the end application requests (for example, creating a virtual disk of 2TB that only takes up 100MB on disk).
I, for one, am sad to see this feature go. For anyone interested in this amazing feature, have a read here: http://www.flexhex.com/docs/articles/sparse-files.phtml