none
Win7 (SMB1) oplock issues RRS feed

  • Question

  • <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman";} span.EmailStyle15 {mso-style-type:personal; mso-style-noshow:yes; mso-style-unhide:no; mso-ansi-font-size:11.0pt; mso-bidi-font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} -->

    Hi there,

    I am observing an issue with Win7 oplock behavior (SMB1 protocol). 

     

    Note: i am enforcing SMB1 protocol between Win7 client and Win7 server.

    I just copied a file 20MB.doc ( remote write ) from win7 client to win7 server. ( I disabled SMB2 and SMB1 is the protocol used ).
    scenario

    1. Win7 client opens the 20mb.doc on Win7 server and acquires a batch oplock
    2. Win7 client writes contents on to the file
    3. Win7 client reads the contest of the file
    4. Win7 client issues QPI  File Basic Info request
    5. Win7 server breaks the batch oplock to L2 oplock
    6. Win7 client does seem to ACK the break
    7. Win7 server timed out  after 1.2 seconds and responds back to QPI File Basic Info
    8. Win7 closes the handle

     

    Questions

    1. Why does a QPI (basic info ) break the batch oplock?

    2. Why does win7 client does not respond to break ( batch to L2 ) ?

     

    I have the tcpdump ( 23MB ). I don't know where to attach.

     

    Any help is much appreciated.

    Saturday, October 31, 2009 3:04 AM

Answers

  • Good morning Jan & Mohan.

    I have verified that the oplock break behavior where a shell folder is open on the target file is indeed 'by design'. Essentially, the shell (Explorer.exe) uses directory management functions (FindFirstChangeNotification, etc - see below for links to MSDN topics) to keep the folder view syncronized with the folder contents. So, this is normal Windows behavior.

    However, if you find a 'spurious oplock break' scenario where the shell behavior does not apply, please do not hesitate to contact us again!

    Directory Management Functions
    http://msdn.microsoft.com/en-us/library/aa363950(VS.85).aspx
     FindFirstChangeNotification
     FindNextChangeNotification
     FindCloseChangeNotification
     ReadDirectoryChangesW

    Regards - and thanks for your patience,
    Bill Wesse

    • Marked as answer by Bill Wesse Thursday, December 31, 2009 1:11 PM
    Thursday, December 31, 2009 1:10 PM
  • Thanks for the feedback! It makes perfect sense. I should have generalized my comment from last December ('I suspect that the shell has a notification set on the file') to something like: ...any notification set on the file by any process may cause this behavior...

    But then, like Curly from the 3 stooges said: "I tried to think, but nothing happened."

    Regards,

    Bill Wesse

     

    • Marked as answer by Bill Wesse Wednesday, April 28, 2010 9:49 AM
    Wednesday, April 28, 2010 9:49 AM
  • As we suspected, other filter drivers i.e. an anti-virus driver, have some hooks on file system drivers. It looks like the anti-virus might be scanning the file at the time of the initial close request, and this triggers the oplock break. This whole thing delays the response. In normal circumstances, your scenario did not require an oplock break.

    After disabling “File System - Auto Protect” feature, the oplock was not broken by the server.

    Also as you confirmed, after disabling Symantec, there is no latency in responding to the close request.

    Thanks again for all your collaboration on this issue.

     

    Regards,

    Edgar

    Friday, June 18, 2010 8:50 PM
    Moderator
  • Hi SyedQ,

    This forum is for software developers who are using the Open Specifications documentation to assist them in developing systems, services, and applications that are interoperable with Windows. The Open Specifications can be found at:Open Specifications
    . Your post does not seem to be related to the Open Specifications documentation set.

    Since the issue is happening when working with a Novell client installed, I would strongly recommned that you contact Novell for support. I am not familiar with their forums or public support options so I can not suggest you any one in particular.

     

    Thanks and regards,


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team
    Sunday, May 29, 2011 1:01 PM

All replies

  • Hi,

       Thanks for your question.   One of our team member will work on your question and respond to you when the investigation is finished.

    Thank!


    Hongwei Sun -MSFT
    Saturday, October 31, 2009 3:03 PM
  • Good morning, and thanks for your post regarding the [MS-SMB] protocol specification. My name is Bill Wesse, from the Protocol Support team; I will be your contact for the issue you raised concerning Win7 SMB/oplock behavior.

    You indicated you have a network capture of the oplock behavior. I would deeply appreciate it if you would email that capture to 'dochelp@microsoft.com' (title: Win7 (SMB1) oplock issues).

    Regards,
    Bill Wesse


    Escalation Engineer
    Monday, November 2, 2009 5:25 PM
  • Good morning! I neglected to ask about the specifics on client activity. Could you advise me of the sequence of operations on the client? That is, what version of Office/Word are you using on the client to open the file, or are you using something else?

    Regards,
    Bill Wesse

    Escalation Engineer
    Monday, November 2, 2009 5:35 PM
  • I have sent the traces to the specified email address.

    I am using copy.exe to copy a file from Win7 client to Win7 server ( dos utility ).

    To clarify on the sequence of the client activities 

    1. From Win7 client's console i executed the following commands to disable SMB2
            sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
            sc config mrxsmb20 start= disabled
    2. Power cycle Win7 client
    3. After reboot, On Win7 client console
           net use z: \\<Win7 server>\<share>  /USER:Administrator ( Win7 client )
           copy 20mb.doc z:\


    Regards,
    Mohan
    Monday, November 2, 2009 8:55 PM
  • Thanks Mohan - I expect to run the test later today (I have some VM configurations to accomplish first).

    Regards,
    Bill Wesse


    Escalation Engineer
    Tuesday, November 3, 2009 2:00 PM
  • Mohan - I have tested the steps you provided (copy a 20MB file from Windows 7 to Windows 7, using the copy command). I tested on 2 Virtual Machines (Windows 7 Ultimate <release>), with SMB2 disabled.

    The SMB Transact2 / Query Path Info / Query File Basic Info should not be causing the Windows 7 target system (server) to issue an Oplock break (SMB Locking Andx). Also, the client should respond to the Oplock break with a follow up SMB Locking Andx with LockType OPLOCK_RELEASE flag (0x02) set.

    Unfortunately, my setup did not reproduce the odd oplock behavior you are seeing. My traces do not show any file read operations, plus all of the Transact2 (Query Path/File/FS info, and set file info all occurred before the writes, and nothing after).

    Did I miss a step?

    1. net use z: \\<Win7 server>\<share>  /USER:Administrator ( Win7 client )
    2. copy 20mb.doc z:\

    ==============================================================================
    BTW - another way to disable SMB2 is shown in the workaround section of the following knowledge base article:

    You encounter poor performance when you use the SMB 2.0 protocol to perform network-related operations, such as ADMT migration, on computers that are running Windows Server 2008 or Windows Vista
    http://support.microsoft.com/kb/950836/EN-US

    ==============================================================================
    References:

    MSDN / MSDN Library / Win32 and COM Development / Windows Development (General) / Specifications / CIFS

    CIFS Packet Formats
    http://msdn.microsoft.com/en-us/library/dd327709.aspx

    [MS-CIFS]: Common Internet File System (CIFS) Protocol Specification
    http://msdn.microsoft.com/en-us/library/ee442092.aspx

    [MS-CIFS]: 3.3.4.2 Server is Notified of an OpLock Break
    http://msdn.microsoft.com/en-us/library/ee441998.aspx

    [MS-CIFS]: 3.2.5.43 Receiving an OpLock Break Notification
    http://msdn.microsoft.com/en-us/library/ee441694.aspx

    Regards,
    Bill Wesse


    Escalation Engineer
    Tuesday, November 3, 2009 8:41 PM
  • Mohan - right after I posted the previous, I realized that I need to redo the test with 'copy /v 20mb.doc z:\'. The verify operation should account for the reads & additional query info calls. I will get to this first thing tomorrow morning (out of time today).

    Regards,
    Bill Wesse

    Escalation Engineer
    Tuesday, November 3, 2009 8:51 PM
  • Thanks Bill

    To clarify on my exact windows version, it is Windows 7 Enterprise Version 6.1 ( Build 7600 ).


    >>Unfortunately, my setup did not reproduce the odd oplock behavior you are seeing. My traces do not show any file read operations, plus all of the Transact2 (Query >>Path/File/FS info, and set file info all occurred before the writes, and nothing after).
    >>Did I miss a step?

    I did the test couple of times so the copy command prompted for overwrite ( Yes/No/xxx). May be overwriting an existing file would trigger these reads and trans2 messages. I did not use /v option.
    Wednesday, November 4, 2009 12:39 AM
  • Good morning Mohan. I have retested, and duplicated the oplock break behavior - but not exactly as you have seen. The server issued an oplock break to L2, which was replied to properly by the client.

    I will email you the captures (both Netmon .cap and tcpdump .pcap). I have additional investigations to do - specifically, in the capture, there is a second break to no oplock.

    1. server sends (Locking Andx) oplock break to Level 2
    2. client response to Locking Andx
    3. server sends (Locking Andx) oplock break to none
    4. no client response in the capture, I will be retesting to ensure no dropped packets

    Regards,
    Bill Wesse


    Escalation Engineer
    Wednesday, November 4, 2009 1:36 PM
  • Thanks for you update Bill.

    I am definitely seeing the problem consistently.

    1. Would Win7 enterprise server behave different from Win7 ultimate ( i am using enterprise 6.1)?
    2. Would copy.exe behave differently for text file and doc file ( i am using doc file )?

    Could you try copying a MS doc file on a Win7 enterprise client and server ?

    Mohan

     
     
    Thursday, November 5, 2009 5:47 AM
  • You are very welcome - my answers are in-line below.

    1. Would Win7 enterprise server behave different from Win7 ultimate ( i am using enterprise 6.1)?

    They should behave the same way; and I will verify that.

    2. Would copy.exe behave differently for text file and doc file ( i am using doc file )?

    The file extension should make no difference in the server or redirector. The trace you sent indicates no attempts to open IStorage streams in the target file, or anything indicitive of filter driver intervention - other than the Locking Andx oplock break.

    Regardless, I will test also with a doc file.

    Hopefully my test setup will misbehave again, so I can yank more info (using Procmon, etc.). I will status you by tomorrow morning at the latest.

    Regards,
    Bill Wesse


    Escalation Engineer
    Thursday, November 5, 2009 12:14 PM
  • Good morning Mohan. So far - after numerous attempts, I have been able to get only one instance of an oplock break from the server (Windows 7 Ultimate and Windows 2008 R2 Enterprise). I tested with both .txt and .doc files - no differences (which is what I expected).

    This is inconvenient for both of us, of course. I will continue to test - while monitoring the file on the server with Procmon. I suspect there is something going on in the server service (netsvcs) that is triggering this - oplock breaks are handled asynchronously in the file server service.

    Is the server your are using under any kind of traffic load? Perhaps there is another condition necessary to cause this on a consistent basis.

    Regards,
    Bill Wesse

    Escalation Engineer
    Friday, November 6, 2009 3:12 PM
  • Bill,

    Thanks for the update.

    >>I have been able to get only one instance of an oplock break from the server (Windows 7 Ultimate and Windows 2008 R2 Enterprise).
    I am seeing this problem only with win7 ultimate client and win7 ultimate server ( i don't see this problem with any other severs  like win2003 and win2008). Are you trying Win7 ultimate client and win7 ultimate server ?

    >> I tested with both .txt and .doc files - no differences
    Thanks for confirming this.

    >>Is the server your are using under any kind of traffic load?
    This server is in a private network and win7 ultimate is the only client accessing it.

    Regards,
    Mohan
    Friday, November 6, 2009 7:32 PM
  • Mohan, I am indeed using Win7 Ultimate on both ends of the file copy - private network, no other systems involved. It happened once, then stopped - with no system reconfigurations. I will just have to keep slugging away at it.

    Regards,
    Bill Wesse

    Escalation Engineer
    Monday, November 9, 2009 2:14 PM
  • Good day Mohan - I will be emailing you some trace utility scripts within the next day or so. We have some setup & test to perform here first (these are new tracing scripts from our developers, that nab plenty from the server / redirector & file system drivers).

    Thanks for your patience!

    Regards,
    Bill Wesse

    Escalation Engineer
    Wednesday, November 11, 2009 4:55 PM
  • Hello Mohan - please let me know if you run into any snags with the data gathering tools. I would be glad to help if needed.

    Regards,
    Bill Wesse

    Friday, November 20, 2009 5:58 PM
  • Good morning Mohan - just checking in with you to ensure you received the test package. Please let me know if you need anything from me!

    Regards,
    Bill Wesse
    Monday, November 30, 2009 4:57 PM
  • Good morning Mohan – I have not heard from you since November 5: please let me know if you wish to continue or discontinue this case.

    I have also sent this message via email to you.

    Regards,
    Bill Wesse

    Wednesday, December 2, 2009 3:51 PM
  • Hello Bill, Hello Mohan,

    because we have had simular issues like this into the past with w2k3 and xp, I am interessted in the ending of this story. Would you please update the thread?
    no sig
    Wednesday, December 2, 2009 8:21 PM
  • Good morning Jan (and Mohan).

    In my November 4 post, I noted I was able to reproduce the spurious oplock break - once, and only once. I proceeded to retry ~100 times, without a repeat of the problem.

    I think this is what we call a 'Heisenbug'. That is, the closer you look, the less often it occurs <g>.

    That said, if either of you have any insight or configuration / order of operation information on making this occur more predictably, I am ready to investigate further.

    Looks like this has been around for quite a while (since Xp at least, and no doubt Win2K - and perhaps NT4x as well). I suspect there is some connection state context in the smb redirector (mrxsmb.sys for Win 2000 through Win 2008, mrxsmb.sys in Vista and beyond) that is responsible.

    Getting a more or less reliable way to elicit this is key; we cannot proceed effectively without that.

    Regards,
    Bill Wesse
    Thursday, December 3, 2009 1:56 PM
  • Good afternoon Jan & Mohan.

    I have finally obtained a 'stable' way to reproduce the spurious oplock break you reported. The missing ingredient was to have a shell folder open on the target folder (where the file gets copied to).

    I should now be able to debug this to see what's up. I suspect that the shell has a notification set on the file, and is reacting to the writes in some way that breaks the oplock.

    I will advise you once I figure out precisely what's occurring; it may be intentional behavior on the part of the shell, but I won't state that authoritiatively until I know exactly what's up.

    Regards,
    Bill Wesse
    Wednesday, December 30, 2009 5:47 PM
  • Good morning Jan & Mohan.

    I have verified that the oplock break behavior where a shell folder is open on the target file is indeed 'by design'. Essentially, the shell (Explorer.exe) uses directory management functions (FindFirstChangeNotification, etc - see below for links to MSDN topics) to keep the folder view syncronized with the folder contents. So, this is normal Windows behavior.

    However, if you find a 'spurious oplock break' scenario where the shell behavior does not apply, please do not hesitate to contact us again!

    Directory Management Functions
    http://msdn.microsoft.com/en-us/library/aa363950(VS.85).aspx
     FindFirstChangeNotification
     FindNextChangeNotification
     FindCloseChangeNotification
     ReadDirectoryChangesW

    Regards - and thanks for your patience,
    Bill Wesse

    • Marked as answer by Bill Wesse Thursday, December 31, 2009 1:11 PM
    Thursday, December 31, 2009 1:10 PM
  • Good morning Bill,

    I could not think, that you work so hard even on Silvester noon: How can I contact your boss recommending a higher payment for you, wishing you a Very Happy New Year?
    Back to the topic, yes, you are on the right path, we are using FindFirstFile aggainst the "server" often to check, if a local copy of the needed file is older as on the "server", to only copy newer ones. Maybe our code coming from older NT4 day's need to be changed, because over the years the behavior on the network inside Windows has changed - because the errors happen more often as in the past?
    Anyway, you brought me on the right path as a super pathfinder you are, thanks a lot Bill.
    no sig
    • Proposed as answer by Jan Kästner Monday, January 4, 2010 8:00 AM
    Monday, January 4, 2010 7:59 AM
  • Hello Jan - thank you very much for the compliments! Perhaps the 'Directory Management Functions' I noted above may be of help in your efforts. Also, there are some new registry settings for SMB2 which you should know about - they control File/Dir information cache on the server (the default values are listed in the post):

    SMB2 Registry Settings
    http://social.msdn.microsoft.com/Forums/en-US/os_fileservices/thread/832d395b-6e6f-4658-8dbb-120138a4cd7c
    FileInfoCacheLifetime, FileNotFoundCacheLifetime, DirectoryCacheLifetime

    Another thing that could come into play when checking for file updates would be to attempt to get a 'no sharing' handle on the file (CreateFile with dwShareMode set to 0). If that fails, someone else has a handle open against it, and you may need to revisit the file later. But you no doubt have already looked into that.

    Regards,
    Bill Wesse

    • Marked as answer by Bill Wesse Monday, January 4, 2010 2:41 PM
    • Unmarked as answer by mohanraj_cit Wednesday, April 28, 2010 8:10 AM
    Monday, January 4, 2010 2:41 PM
  • After a lot trail & error configuration changes, it was discovered that Symantec Antivirus (File System - Auto protect) running on my Win7 server seem
    to have opened the file being copied. This triggered the server to break the oplock. ( visible in procmon). 

    When Symantec (File System - Auto protect) was disabled on the windows 7 server, oplock is not broken and copy went through fine.

    Hope this helps.

     

     

     

    Wednesday, April 28, 2010 8:14 AM
  • Thanks for the feedback! It makes perfect sense. I should have generalized my comment from last December ('I suspect that the shell has a notification set on the file') to something like: ...any notification set on the file by any process may cause this behavior...

    But then, like Curly from the 3 stooges said: "I tried to think, but nothing happened."

    Regards,

    Bill Wesse

     

    • Marked as answer by Bill Wesse Wednesday, April 28, 2010 9:49 AM
    Wednesday, April 28, 2010 9:49 AM
  • Hi Bill,

    Still there seems to be some interesting questions for which i don't know the answer.

    * Why would Symantec open the file always at the same time ( middle of writes) ?

    * Why did not "Windows 7" client respond to "Batch to L2" oplock break.  (eventually server timed'out)

    Thursday, April 29, 2010 12:54 AM
  • Hello Mohanraj,

     I wanted to let you know that Bill has been temporatily assigned to another project.  For the first question you should get in touch with Symantec for your answer. For the Window's client question, a member of our team will be contacting you soon  to continue working with you on this question

     

    Thanks

    John Dunning

    Friday, May 7, 2010 3:41 PM
  • Hello Mohanraj,

     

    I'm also with the protocols team.  I am reviewing this thread and researching this for you.

     

    Bryan Burgin

     

    Friday, May 7, 2010 5:58 PM
    Moderator
  • Mohan,

     

    Today I attempted to repro this issue for you without success.  The root cause my rely on something specific to your environment.  So, what I would like you to do is to capture ETW traces from your Windows 7 Ultimate client.  I sent mail to the e-mail Bill used when working with you.  If you did not receive it, please let me know.

     

    Bryan S. Burgin
    Senior Escalation Engineer
    US-CSS DSC Protocols Team

    Thursday, May 13, 2010 10:25 PM
    Moderator
  • Hi Bryan,

     

    >> Why did not "Windows 7" client respond to "Batch to L2" oplock break.  (eventually server timed'out)

    ETW/ETL log and netmon trace files have been uploaded to Microsoft portal

     

    Regards,

    Mohan

    Thursday, May 20, 2010 4:45 PM
  • Hi Bryan,

    Were you able to find anything from the traces i uploaded ?

    I wrote a simple VC++ program on my windows 7 (workstation) to check how it behaves for break requests. Client was responding consistently for breaks from Batch->L2.

    Then i took a close look at both the tcpdumps and came up with theory.

    This problem (win7 client not responding to batch->L2 oplock break) happens only when there is an outstanding request. In my testing i see this problem only when SMB_CLOSE/QUERY_PATH_INFO is outstanding. Server decided to send the oplock break when there an outstanding request for Win7 client ( server is still processing SMB_CLOSE/QUERY_PATH_INFO request and not yet responded to the client).

    Is it possible for a Win7 client to drop an asynchronous requests from server (like oplock break, nt_notify) when it is actually waiting for a response to the request it sent ?

    Regards,

    Mohan

    Friday, May 21, 2010 5:25 PM
  • Mohan,

    This post is to let the community know we have taken this thread offline and are working with you to resolve the issue. I will post a summary of the answer once we complete the investigation of your scenario.

    Regards,

    Edgar

    Monday, June 14, 2010 10:49 PM
    Moderator
  • As we suspected, other filter drivers i.e. an anti-virus driver, have some hooks on file system drivers. It looks like the anti-virus might be scanning the file at the time of the initial close request, and this triggers the oplock break. This whole thing delays the response. In normal circumstances, your scenario did not require an oplock break.

    After disabling “File System - Auto Protect” feature, the oplock was not broken by the server.

    Also as you confirmed, after disabling Symantec, there is no latency in responding to the close request.

    Thanks again for all your collaboration on this issue.

     

    Regards,

    Edgar

    Friday, June 18, 2010 8:50 PM
    Moderator
  • Dear Bill,

     

     We are facing an odd issue with our Windows 7 workstations with novell netware server 6.5. When two users simultaneously trying to access a file, it showing status 99 (file locked) on the machine. However, when doing same with windows xp as client workstation shows no error and runs smoothly. We have already checked the oplock disabled on novell netware and tried with file caching on/off with novell client properties. Please suggest as how we can fix this issue.

    Sunday, May 29, 2011 11:02 AM
  • Hi SyedQ,

    This forum is for software developers who are using the Open Specifications documentation to assist them in developing systems, services, and applications that are interoperable with Windows. The Open Specifications can be found at:Open Specifications
    . Your post does not seem to be related to the Open Specifications documentation set.

    Since the issue is happening when working with a Novell client installed, I would strongly recommned that you contact Novell for support. I am not familiar with their forums or public support options so I can not suggest you any one in particular.

     

    Thanks and regards,


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team
    Sunday, May 29, 2011 1:01 PM