Thoughts on correct support for Windows Previous versions

Satyajit Deshmukh satyaji.deshmuk at
Tue Jan 27 17:17:43 MST 2015

A minor correction is needed in the patch attached previously-
diff --git a/source3/smbd/trans2.c b/source3/smbd/trans2.c
index 16498b3..57d7bde 100644
--- a/source3/smbd/trans2.c
+++ b/source3/smbd/trans2.c
+                       /*
+                        * If the file is a previous version, Windows expects
+                        * FS_INFO to indicate that it is on an ROFS.
+                        */
+                       if (fsp && fsp->is_previous_version &&
+                           !fsp->is_directory)
+                               additional_flags != FILE_READ_ONLY_VOLUME;

I believe it should be-
additional_flags |= FILE_READ_ONLY_VOLUME;


On Mon, Jan 26, 2015 at 4:57 PM, Richard Sharpe
<realrichardsharpe at> wrote:
> On Mon, Jan 26, 2015 at 4:40 PM, Jeremy Allison <jra at> wrote:
>> On Sun, Jan 25, 2015 at 05:49:35PM -0800, Richard Sharpe wrote:
>>> When we implemented support for Windows Previous Versions at Panzura
>>> we started with one of the existing Shadow Copy modules and adapted it
>>> to the SnapShots provided by the file system (ZFS-based), and life
>>> seemed good.
>>> Then in came the bug reports from QA and we were forced to check what
>>> Windows actually did.
>>> At first I assumed that Windows would return an error like
>>> STATUS_ACCESS_DENIED if one tried to open a previous version for
>>> write-like access, eg, opening a previous version in Notepad or
>>> wordpad, but this turned out to be incorrect. In fact, Windows allows
>>> you to do that, at least according to our tests, but returns
>>> We also found that Windows will ask for FS_INFO on open files,
>>> presumably to check that the volume is write protected.
>>> This does lead to some interesting problems, because it means that
>>> when the client asks for WRITE access to a file and the ACL allows it,
>>> you then try to open the file for WRITE access, but the file system
>>> denies it (or at least ours did) and returns EROFS. You have to turn
>>> around and open the file RO and pretend that you opened it for WRITE
>>> to get the correct behavior.
>>> Unfortunately, at Panzura we modified Samba too much, and I am now
>>> convinced that most of the changes could have been done in the VFS
>>> module we had.
>>> However, there are a few small changes I think are needed. One is to
>>> add a field to the FSP to record whether or not a file is a previous
>>> version. This would only ever be set by a VFS module providing
>>> previous versions functionality, but it seems simpler than adorning
>>> the FSP with an extension and is needed in one place in Samba.
>>> The other one is to pass an FSP into one function and to return the
>>> correct value when Windows asks for FS_INFO on an open file.
>>> Attached is a patch for discussion that makes those changes.
>>> However, this might not be enough because VFS calls like ntimes does
>>> not get passed an FSP (something I want to fix at some time as well,
>>> as soon as 4.2 is finally cut.) (The only way to return
>>> STATUS_MEDIA_WRITE_PROTECTED from VFS modules is if all functions that
>>> implement WRITE-like behavior get access to the FSP.)
>>> Over the next few weeks I will try to get a capture of the behavior of
>>> Windows with respect to getting FS_INFO on an open file to document
>>> this.
>> Yep, that's the next step. We need to know exactly what
>> behavior we need to emulate to make the Windows Previous Versions
>> work like a Windows server, then I'll be happy to add tests
>> and make any needed VFS changes.
> OK, I will try to bring this to the top of my priority queue. I would
> also like to get changes to the VFS in such that we provide an FSP to
> all VFS functions that deal with files. There are some that don't as
> yet get an FSP.
> However, I think this change has to wait until 4.3.
> --
> Regards,
> Richard Sharpe
> (何以解憂?唯有杜康。--曹操)

More information about the samba-technical mailing list