Microsoft's new file system: ReFS

Nick_Lowe · January 17, 2012, 9:16am

Building the next generation file system for Windows: ReFS

http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx

This is definitely worth a read!

The bit that really concerns me is that it appears that it is going to be released in a thoroughly half baked, unfinished form:

"Q) What semantics or features of NTFS are no longer supported on ReFS?

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."

Prima facie, this will -massively- break existing code…

Prokash_Sinha-1 · January 17, 2012, 1:44pm

Thanks for the link…

I was hoping log structured FS feature would be supported… It’s Myth in
SSD space

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, January 17, 2012 6:19 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Microsoft’s new file system: ReFS

Building the next generation file system for Windows: ReFS

http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-f
ile-system-for-windows-refs.aspx

This is definitely worth a read!

The bit that really concerns me is that it appears that it is going to be
released in a thoroughly half baked, unfinished form:

"Q) What semantics or features of NTFS are no longer supported on ReFS?

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."

Prima facie, this will -massively- break existing code…

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Christian_Allred · January 17, 2012, 2:02pm

> Prima facie, this will -massively- break existing code...

We will be talking about ReFS at the Plugfest next month. As for breaking existing code, sure that's possible, but you'd have to basically do it on purpose. For Windows 8 ReFS will only be available on Server SKUs, and won't be available as a boot volume. So you'll have to purposely create an ReFS data volume to test code on. For a filter you'd also have to ignore the fact that FLT_FSTYPE_REFS was handed to you in your InstanceSetupCallback routine. Everybody's paying attention to the VolumeFilesystemType, right?

Christian [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Nick_Lowe · January 17, 2012, 2:27pm

The compatibility nightmare that I see is code that does not properly check for a file system feature before attempting to use it and doesn’t have a well tested fallback/error path.

Even this comes with a caveat:

The FILE_SUPPORTS_HARD_LINKS, FILE_SUPPORTS_EXTENDED_ATTRIBUTES, FILE_SUPPORTS_OPEN_BY_FILE_ID and FILE_SUPPORTS_USN_JOURNAL flags were only added in NT 6.1 (Windows 7 and Windows Server 2008 R2) and yet support for all of them has been implicit since NTFS 3.0 that was introduced with NT 5.0 (Windows 2000). A literal check for NTFS by file system name would therefore also be needed to determine the implicit presence of these features.

(And it is important to ensure that such literal checks for NTFS by name are only performed to determine the implicit support of these features and for no other purpose to ensure that applications are as forward compatible with other file systems as is reasonably possible by not taking a dependency on NTFS.)

For applications that depend on any of the features above, appropriate workarounds will have to be found or a declaration made that they are not compatible with the underlying file system due to a lack of feature support.

Nick_Lowe · January 17, 2012, 2:31pm

By “features above”, I meant to add:

Mapped to file system attribute flags, the following appear as if they are not going to be supported in ReFS:

FILE_NAMED_STREAMS
The file system supports named streams.
FILE_SUPPORTS_OBJECT_IDS
The file system supports object identifiers.
FILE_FILE_COMPRESSION
The file system supports file-based compression.
FILE_SUPPORTS_ENCRYPTION
The file system supports the Encrypted File System (EFS).
FILE_SUPPORTS_TRANSACTIONS
The file system supports transactions.
FILE_SUPPORTS_SPARSE_FILES
The file system supports sparse files.
FILE_SUPPORTS_HARD_LINKS
The file system supports hard links.
FILE_SUPPORTS_EXTENDED_ATTRIBUTES
The file system supports extended attributes.
FILE_VOLUME_QUOTAS
The file system supports per-user quotas.

Christian, might you confirm that this list is correct?

Regards,

Nick

Phil_Barila-2 · January 17, 2012, 2:32pm

I think the statement refers more to app code than drivers. I'm sure
Explorer will provide an alternative to the :Zone.Identifier:$DATA streams,
but what about the rest of the world?

Phil

Philip D. Barila

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Tuesday, January 17, 2012 12:05 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Microsoft's new file system: ReFS

Prima facie, this will -massively- break existing code...

We will be talking about ReFS at the Plugfest next month. As for breaking
existing code, sure that's possible, but you'd have to basically do it on
purpose. For Windows 8 ReFS will only be available on Server SKUs, and
won't be available as a boot volume. So you'll have to purposely create an
ReFS data volume to test code on. For a filter you'd also have to ignore
the fact that FLT_FSTYPE_REFS was handed to you in your
InstanceSetupCallback routine. Everybody's paying attention to the
VolumeFilesystemType, right?

Christian [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:

To unsubscribe, visit the List Server section of OSR Online at

OSR_Community_User · January 17, 2012, 2:33pm

> We will be talking about ReFS at the Plugfest next month. As for breaking existing code, sure that’s possible, but you’d have to basically do it on purpose. For Windows 8 ReFS will only be available on Server SKUs, and won’t be available as a boot volume. So you’ll have to purposely create an ReFS data volume to test code on. For a filter you’d also have to ignore the fact that FLT_FSTYPE_REFS was handed to you in your InstanceSetupCallback routine. Everybody’s paying attention to the VolumeFilesystemType, right?

Either they are or they never left the building I found FltMgr coupling with non-MS file systems to be… an extraordinary journey!

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

Christian_Allred · January 17, 2012, 4:43pm

> Christian, might you confirm that this list is correct?

For the first version of ReFS at least, yes. Bear in mind that ReFS will evolve over time, particularly in response to customer feedback. That is to say, this isn't necessarily the final list of features it will support in future versions. NTFS didn't have the raft of features it has today when it first came out.

Again, we will be covering what ReFS means for filters in particular at Plugfest in February.

Christian [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Nick_Lowe · January 17, 2012, 5:00pm

I do not think its the inevitable evolution that is of concern to many, rather it is the potential impact of it imminently.

Please don’t take offence when I say, dispassionately, that ReFS appears to be a mainly a regression of NTFS, with many sticks and few carrots. With all its missing features, it looks to be far, far too premature to launch.

(If it is not possible to even boot Windows from the filesystem, it should be clearly not yet fit for purpose / mature enough to release.)

Surely integrity streams and scrubbing, which are evolutionary and not revolutionary features, could have made it to NTFS without the mass exodus of features seen here in this new file system?

Others are already commenting about how Microsoft is taking file systems backwards:
http://girlyngeek.blogspot.com/2012/01/microsoft-returns-customers-to-past.html

Regards,

Nick

mm1 · January 17, 2012, 5:29pm

Those articles are presumably pure marketing, as they always are. The
corporate blog is just marketing. Who knows what’s really going to happen,
and on what time schedule? I mean, you can probably find someone there who
will maintain that this is actually WinFS at long last. They (and all
companies) are always talking about the future. I mean, exactly how many
names has ‘COM’ had, all for a technology that is basically a table of
function pointers? And then there’s ‘.NET,’ as in ‘wnet.’ Three tiered
middleware based on VB, Access & MTS, which would lower your TCO while
increasing your ROI, all in an object-oriented, internet aware manner. Win8
was going to drop support for legacy FSF’s (maybe it did). And any day
know, there will be no unmanaged code.

I’m not saying that the technology itself is bullshit, only that we don’t
know what it is yet, and taking a corporate blog at face value is dubious,
IMO*

Why not wait and see what comes out in a month or so in the way of
information about them?

I don’t know what this FS is all about, and over the seven years or so that
I’ve been around to observe, Microsoft has done a lot of things that I have
personally found baffling, sometimes even where considered in the light of
the fact that their internal forces/pressures sometimes have historically
taken precedence over those of their competition (IMO), but I’m betting
against them messing with persistence of the OS just for fun, and dropping a
bunch of features suddenly. That would seem unlikely to me, at least.

Maybe it won’t apply in this case, but I think that one thing that even the
staunchest of MSFT critics would have to acknowledge is that they have done
a remarkable job over the years not breaking the staggering amount of old
stuff out there.

(If it is not possible to even boot Windows from the filesystem, it should
be clearly not yet fit for purpose / mature enough to release.)

To me, this indicate that they have some sort of plan here, one which is not
going to be complete, sudden replacement.

*unless of course it is http://blogs.msdn.com/b/doronh/

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, January 17, 2012 2:03 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Microsoft’s new file system: ReFS

I do not think its the inevitable evolution that is of concern to many,
rather it is the potential impact of it imminently.

Please don’t take offence when I say, dispassionately, that ReFS appears to
be a mainly a regression of NTFS, with many sticks and few carrots. With all
its missing features, it looks to be far, far too premature to launch.

(If it is not possible to even boot Windows from the filesystem, it should
be clearly not yet fit for purpose / mature enough to release.)

Surely integrity streams and scrubbing, which are evolutionary and not
revolutionary features, could have made it to NTFS without the mass exodus
of features seen here in this new file system?

Others are already commenting about how Microsoft is taking file systems
backwards:
http://girlyngeek.blogspot.com/2012/01/microsoft-returns-customers-to-past.h
tml

Regards,

Nick

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Malcolm_Smith · January 17, 2012, 10:09pm

On 01/17/2012 02:02 PM, xxxxx@gmail.com wrote:

Thanks Nick for taking the time to express your views plainly.

Please don’t take offence when I say, dispassionately, that ReFS appears to be a mainly a regression of NTFS, with many sticks and few carrots. With all its missing features, it looks to be far, far too premature to launch.

No offense taken. As you can see from the blog post, the main goal of
the initial release is to transition to a radically different storage
engine than NTFS would use. This storage engine has a lot of advantages
over NTFS, many of which are not fully utilized. I know many filter
writers might disagree, but I’m not sure that a good comparison of
filesystems is based on the features that are supported, but the quality
of that support.

(If it is not possible to even boot Windows from the filesystem, it should be clearly not yet fit for purpose / mature enough to release.)

By that logic NTFS would be the only filesystem included with Windows.
As people on this list know, boot implies many things, and the set of
those things grows each release. Even the simplest thing like paging
file support is a significant undertaking (and most filters don’t
undertake it.) Like all software developers, we face the choice of
delay in the hope of shipping a perfect product someday, or shipping
what we have and being honest about how to characterize it. By making
this server only and non-boot, our message is clear: this filesystem is
designed for the future, but we have a long road ahead of us to get there.

Surely integrity streams and scrubbing, which are evolutionary and not revolutionary features, could have made it to NTFS without the mass exodus of features seen here in this new file system?

Scrubbing is possible against NTFS, and the Win8 infrastructure is
designed to support that. Integrity streams are more difficult. I was
tasked with investigating the feasibility of doing this in NTFS, and
many performance and synchronization issues quickly became apparent.
Worse, the end-to-end story is incomplete: if each write is to a new
location with a unique checksum, but the metadata updates continue to go
through a write-in-place log and MFT, we’re still left with torn writes
that could render the “integrity” file as corrupt.

Surendra hinted at this in the blog post, but the real effect of ReFS is
that our recovery story after power loss is an order of magnitude better
than NTFS before we’ve shipped our first beta release. That gap can be
expected to widen.

As Christian has been saying, this initial release is partly for
feedback. Not all of the features cut will be cut forever. I can’t
give you a list of what will come back and when, because I honestly
don’t know - that will be driven by feedback.

http://girlyngeek.blogspot.com/2012/01/microsoft-returns-customers-to-past.html

I read this blog post earlier today, and I think it starts with a great
analysis and ends with a simplistic feature comparison. One might
rhetorically ask which of those filesystems supported boot in their
first release, for example. We are still at the beginning of a long road.

I certainly look forward to having some engaging discussions this plugfest.

M // ReFS co-author

rod_widdowson · January 18, 2012, 3:33am

> I was hoping log structured FS feature would be supported…

Been there done that I have lost large chunks of my life developing Log
structured file systems. Log structuring is missing a real silver bullet to
make it worth the huge cost/risk of implementation in the file system space.
It enables a whole bunch of things that sounds really really exciting, but
when it comes to it they all have existing non log structured
implementations which do the job (less well but do it). You end up driving
program management mad since you cannot give them one thing which it does
better than everything else and product management mad because it is an all
or nothing thing and you cannot do just a bit, ship and add the rest later.
From these posts it feels like there is a push to get something out in the
face of ZFS and they are doing it bit by bit. I know little about ZFS but
what I have heard make me feel that it is a shame that ZFS wasn’t a fit.

IMO, In a requirements led development process LSFS will always lose, unless
the requirement is “implement log structuring”.

Microsoft have (or have had) access to many of the developers and some of
the managers who worked on one of the few commercial Log structured file
systems (including one very highly placed individual) so I’m guessing that
they thought long and hard about it. From the little I’ve picked up it
feels like a sensible technical route to service the market so kudos to the
development team for that.

I look forward to hearing all about it next month - but of course that will
all be under NDA and so at that stage we’ll have to be very careful about
how we talk about it.

It’s Myth in
SSD space

Don’t forget storage for virtual machine (or so the rumor goes)

Nick_Lowe · January 18, 2012, 4:55am

Malcolm,

Thank you for the thorough and thoughtful response, and sorry for what now seems to be a knee jerk reaction on my part. The blog post read initially, to me, with the tone that all the missing features were considered unnecessary and deprecated:

"The key goals of ReFS are:

Maintain a high degree of compatibility with a subset of NTFS features that are widely adopted while deprecating others that provide limited value at the cost of system complexity and footprint…"

It then said:

"Q) What semantics or features of NTFS are no longer supported on ReFS?

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."

If a far more iterative, piecemeal approach is intended in response to customer feedback, then it is my comments are too premature and not the file system.

“I’m not sure that a good comparison of filesystems is based on the features that are supported, but the quality of that support.”

Agreed. From a filter perspective, the features mean a whole lot less - ultimately, however, they all exist to serve user mode - and it is there that the missing features will be painful. From my perspective, it is ADS and TxF that are the two that have the potential to really hurt. For others, it will be other features.

Regards,

Nick

OSR_Community_User · January 18, 2012, 12:29pm

> face of ZFS and they are doing it bit by bit. I know little about ZFS but

what I have heard make me feel that it is a shame that ZFS wasn’t a fit.

I’ve heard that ZFS is faster then NTFS in many particular cases, in some of them - much faster.

Nevertheless, NTFS is claimed to be faster then most classic UNIX FS’s, including Apple’s HFS+.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Peter_Viscarola_OSR · January 18, 2012, 1:46pm

I was *really* surprised, and not in a good way, that alternate named data streams aren’t being supported. In my view, this is a feature that people are finally starting to use and to count on.

I guess I find the lack of ADS support curious, because it just doesn’t seem like something that’d be that difficult or time-consuming to implement. You’ve got to architect for it on the front end in any case, assuming you ARE going to support it eventually. And once you have a default data stream, it has a name… you might as well have alternate data streams. No?

Then again I’m not THE File System Guy here at OSR either,

Peter
OSR

mm1 · January 18, 2012, 2:15pm

>In my view, this is a feature that people are finally starting to use and
to count on.

Like IE, for example.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Wednesday, January 18, 2012 10:49 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Microsoft’s new file system: ReFS

I was *really* surprised, and not in a good way, that alternate named data
streams aren’t being supported. In my view, this is a feature that people
are finally starting to use and to count on.

I guess I find the lack of ADS support curious, because it just doesn’t seem
like something that’d be that difficult or time-consuming to implement.
You’ve got to architect for it on the front end in any case, assuming you
ARE going to support it eventually. And once you have a default data
stream, it has a name… you might as well have alternate data streams. No?

Then again I’m not THE File System Guy here at OSR either,

Peter
OSR

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Don_Burn · January 18, 2012, 3:52pm

I too am surprised about this, including the fact that a number of my
clients who visited Redmond and were considering using alternate data
streams were encouraged of the last few years to do so. Their comments
on Microsoft this week are not printable, or something one says in
polite company.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@osr.com” wrote in message news:xxxxx@ntfsd:

>

>
> I was really surprised, and not in a good way, that alternate named data streams aren’t being supported. In my view, this is a feature that people are finally starting to use and to count on.
>
> I guess I find the lack of ADS support curious, because it just doesn’t seem like something that’d be that difficult or time-consuming to implement. You’ve got to architect for it on the front end in any case, assuming you ARE going to support it eventually. And once you have a default data stream, it has a name… you might as well have alternate data streams. No?
>
> Then again I’m not THE File System Guy here at OSR either,
>
> Peter
> OSR

Malcolm_Smith · January 18, 2012, 9:19pm

On 01/18/2012 12:52 PM, Don Burn wrote:

I too am surprised about this, including the fact that a number of my
clients who visited Redmond and were considering using alternate data
streams were encouraged of the last few years to do so. Their comments
on Microsoft this week are not printable, or something one says in
polite company.

I’m sorry for your clients.

As I’m sure you appreciate, Microsoft is a big company with healthy
internal disagreements. It is always a constant challenge to translate
that into a consistent external position, notwithstanding that our
customers would always like us to do exactly that.

Again, I’m sure everyone on this list appreciates the tradeoffs with
named streams. They will be lost when a file is moved to a filesystem
for removable media, when it is sent through the internet via most
protocols, when it is compressed into common archive formats, when it is
burned to optical media, when it is saved to many NAS devices, etc, etc…

We’ve ended up in a world where named streams can be used either for
metadata that can (and will!) be sacrificed, or for metadata that is so
tightly coupled into local storage that it only has meaning so long as
the data resides in a fixed place. That is, it can be an important
feature for filters who manage local storage, but cannot be relied on
consistently by applications.

As I’ve mentioned previously, the initial release of ReFS is largely for
feedback. It will be interesting to see how impacted the ecosystem is
by the absence of this feature. (I’m sure this conversation will be
continued in the upcoming plugfest as well.)

“xxxxx@osr.com” wrote in message news:xxxxx@ntfsd:
>> I was really surprised, and not in a good way, that alternate named
>> data streams aren’t being supported. In my view, this is a feature
>> that people are finally starting to use and to count on.

As per above, I’m curious who is counting on (in a strict, reliance
sense) this feature other than NTFS-specific filters that won’t even
attach to ReFS without alteration.

>> I guess I find the lack of ADS support curious, because it just
>> doesn’t seem like something that’d be that difficult or time-consuming
>> to implement. You’ve got to architect for it on the front end in any
>> case, assuming you ARE going to support it eventually. And once you
>> have a default data stream, it has a name… you might as well have
>> alternate data streams. No?

As the blog post stresses, the front end code of ReFS is inherited from
NTFS and we retain a lot of named stream code. That said, there is a
lot of simplification that can come from not having named streams. This
obviously includes things like stream deletions and implicit file
deletions, interesting sharing mode and oplock rules, etc. Less obvious
(and more important) to ReFS are various cache lifetime issues, which
would require our rules to diverge quite significantly from NTFS. NTFS
keeps all metadata in a cache for the MFT; ReFS has per-file metadata,
so opening a named stream requires us to initialize the default stream
and keep it around for the lifetime of the named stream, etc. Not
terribly hard, but still significant changes.

The real point though is that software is about priorities, and getting
the core storage changes done was more important than functional parity.

- M

OSR_Community_User · January 22, 2012, 1:49pm

Having been involved in building multiple file systems from scratch, I can certainly appreciate the complex trade-offs between “supporting legacy stuff” and “building something within our lifetime.” Further, I can also appreciate the complexity of adding almost anything to an existing file system (certainly a 20+ year old existing file system) and the rationale for making a clean break.

I’m sure there are many healthy and unhealthy internal disagreements with respect to Microsoft. One thing that (being an outsider) has been rather discouraging under the current management model is that external feedback is neither solicited nor welcome. While I’m certain that internal groups represent a broad range of concerns and constituencies, it seems exceedingly unlikely that they do so in a way that is consistent with the actual needs of the external population. Indeed, my best guess is that it tends to skew towards a small number of customers that represent what is viewed as specific strategic interests. So, it should not come as a surprise when the work is unveiled to a crowd that is almost assuredly OUTSIDE the small strategic customer base that it does not meet with the overwhelming approval of said crowd.

I’m sure this is a great project on which to work - I remember having these discussions about recoverability and reliability of storage media over 20 years ago and if anything the problems have simply intensified - and with IBM’s announcement of 20 atom discreet magnetic particles, it seems clear that densities are going to continue to improve in storage media (and reliability will likely take a corresponding hit, much like it did with previous technologies to enhance recording density. Personally, I’ve always enjoyed the obscure field of Byzantine failure, and it will be interesting to see how you’ve chosen to address some of them.

As for the lack of features, we had to deal with crippled file systems 20+ years ago and chose to augment the capabilities of existing file systems through a layering technique, in which we added a layer of functionality above the existing file system. While not identical, it is reminiscent to the approach we’ve taken with the OSR data modification kit. Since we can add encryption, compression, reparse points, alternate data streams, and other features on top of existing down level file systems, I’m viewing ReFS as simply being one more opportunity for us to offer a value added solution.

Of course, Microsoft has a unique ability to change critical applications on the platform that nobody else has. So while other file systems vendors had to *add* alternate data streams (and lie to claim they were NTFS) to support SQL and Exchange, I presume those teams will simply change their own products to accommodate the restricted feature set of ReFS (since they would both be natural targets for same.)

I’ve hesitated adding transaction support (TxF) to our own DMK because it has such limited usability. One benefit of the decision to omit its support in ReFS is that it effectively means transactions will continue to be a marginal feature into the forseeable future (so I can defer solving that particular problem into the future, at least.)

So, Kudos to Malcom and the rest of the ReFS team on surviving long enough to at least preview (note that a number of new file systems inside Microsoft have died prior to getting to this stage, such as OFS and WinFS.)

Tony
OSR

Nick_Lowe · January 22, 2012, 7:24pm

Those who write with a dependency on alternate, named streams do so fully in the knowledge of their limitations.
Applications with a strong dependency on the feature are therefore typically found only in closed, managed environments, where both the storage and the backup of data are well controlled and well understood.
These deployments are going to be, by nature, far more off the radar, often in private, domain specific services. Because of this, as Raymond Chen would say, perhaps Microsoft are guilty of wearing the googles here by seeing things from a biased perspective:

http://blogs.msdn.com/b/oldnewthing/archive/2011/05/12/10163578.aspx

I, for one, have made extensive use of TxF in the applications that I have worked on, it is a great feature that allows developers to massively cut down on the amount of code that they need to achieve reliable, robust operation.

I further expect that this is one feature that will most likely make a return as it is now used so heavily by updates and service pack installation.

It has always been a huge pity that transactions have never been supported over SMB. This, in my opinion, has heavily curtailed adoption of the feature it is simply too incomplete to use generally.

At the native services API, transactions have also been poorly implemented and documented:

There is no NtCreateFileTransacted, NtOpenFileTransacted or NtQueryAttributesFileTransacted as, originally, implicit, ambient transactions were to be supported via the CurrentTransactionHandle member of the TEB with Win32 offering GetCurrentTransaction and SetCurrentTransaction against the the native system service’s RtlGetGurrentTransaction and RtlSetCurrentTransaction (both still undocumented). It was eventually felt, however, that this changed the semantics for existing code too much and could lead to many intricate, complex, random and hard-to-debug issues coming to the fore, so an explicit model was decided on.

An explicit model therefore came to be implemented. That, by itself, is all well and great, but it was rushed and implemented poorly. The explicit model was tacked on in the Win32 subsystem for the most part, yet was left in an inconsistent state at the native services layer behind the scenes. A complete failure of the abstraction that NT’s subsystem model is meant to offer…

NtCreateFile, NtOpenFile and NtQueryAttributesFile still all work implicitly and require the use of the CurrentTransactionHandle member of the TEB, yet for the registry which also supports transactions (TxR) there is NtCreateKeyTransacted, NtOpenKeyTransacted, NtOpenKeyTransactedEx that require the transaction to be supplied explicitly as a parameter and completely ignore the CurrentTransactionHandle member of the TEB.

This inconsistency was not resolved in Windows Vista SP1/Server 2008, in Windows 7/Windows Server 2008 R2 and still has not been resolved as of the Windows 8 Developer Preview. Bluntly, that is terrible and there is little to no by way of an obvious explanation…

The documentation for ZwCreateTransaction claims that the timeout parameter is in seconds, but it actually takes units of 100 nanoseconds with negative values being relative, positive being absolute.

TRANSACTION_PROPERTIES_INFORMATION is also incorrectly documented in the same way. This, obviously, has not been noticed by others.

Cheers,

Nick