All known 2.2.1 showstoppers fixed..

[Nick Demou]

Once again the team should have done great work! I'm looking forward to get
the final code running.

Just for the record I have reported this minor bug and never had a response
so I will mention it again now. I DO NOT BELIEVE YOU SHOULD DELAY 2.2.1 FOR
IT but if it is very easy to fix then why not (even the smallest bugs are
live creatures who deserve some honor :-)

In a a samba 2.2.0 on a redhat 7 PC:

1) I create a file in samba and it gets a created/modified time of say
06:00:09
2) I am using DOS xcopy to copy it to a win98 client, the copy has a time of
06:00:08
whoops! the copy looks as if it is older than the original. In my case this
is a problem because I rely on time stamps to keep an updated replica of the
samba service.
If I copy through windows everything works fine.
3) I am reading the manual and dos filetime resolution seems to deal with
this situation:
<<<from the man page
Under the DOS and Windows FAT filesystem, the finest granularity on time
resolution is two seconds. Setting this parameter for a share causes Samba
to round the reported time down to the nearest two second boundary when a
query call that requires one second resolution is made to smbd(8) .
>>>

So, I set dos filetime resolution to yes but nothing changes

Have I got it right? Is this the option that has to do with my problem. I
would be sure if the man page did not continue with this text that seems to
clarifying that the use of this setting is for a very specific situation
completely diferent from mine:
<<<
This option is mainly used as a compatibility option for Visual C++ when
used against Samba shares. If oplocks are enabled on a share, Visual C++
uses two different time reading calls to check if a file has changed since
it was last read
...
Setting this option causes the two timestamps to match, and Visual C++ is
happy
>>>