Clients updating against an SMB Internal LiveUpdate Server may occasionally fail to update
TECH97610
Last Updated January 19, 2009
It is rare for this type of access collision to occur in all but the largest of environments which will see the highest load levels, and are most likely to see multiple simultaneous read/copy requests for the same file via LiveUpdate. However, neither HTTP or FTP display this type of limitation (both of these access protocols do support multiple simultaneous file read requests), and as such our principle recommendation would be for our larger customers to distribute the AV Definitions via FTP or HTTP.
If it is necessary to distribute the definitions via SMB Shares, then it may be necessary to schedule multiple LiveUpdate sessions or implement "Continuous LiveUpdate" to ensure that the client will re-try the connection if it is initially refused access.
Any changes to the way in which LiveUpdate handles the SMB Access Denied messages should be raised in the Symantec Connect Ideas forum, as this is the most appropriate location for Product Enhancement Requests.
References
CreateFile API
- http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx
Optimizing Applications for Remote File Access Over WAN
- http://download.microsoft.com/download/f/2/1/f2146213-4ac0-4c50-b69a-12428ff0b077/Optimizing_Applications_for_Remote_File_Access_Over_WAN.pptx
Technical Information
Operating system (File System) access to any file is via the CreateFile API. There are a variety of acccess levels and access methods supported by this API, and the type of access granted will be dependent upon any pre-existing access operations in place, in combination with the ShareMode and DesiredAccess flags.
When an application such as IIS attempts to access a local file for read purposes, it uses the CreateFile "GENERIC_READ" (DesiredAccess) and "FILE_SHARE_READ" (Sharemode). This means that while IIS is accessing the file (and providing it to the user), a separate process (another IIS worker thread, or some other access) can request access and gain similar permissions. This means that IIS can "serve" the same file to multiple simultaneous connections.
However, when a remote computer attempts to access a shared file via SMB, this communication is mediated by the application requesting access to the file in its local OS. The local OS verifies whether the file already exists in its local SMB cache. If the file is not already cached, it then initiates a connection to the remote server to request the file. the server verifies if the file is already cached for that particular session. if it is not, it then attaches to the file via the CreateFile API. This SMB connection is always established as "GENERIC_READ | GENERIC_WRITE" (DesiredAccess) with a "FILE_SHARE_READ" ShareMode. Once the file has been copied into the SMB cache for this connection, The Server will close the "CreateFile" access to the requested file, return the copy to the requesting client, and (if requested) maintain an OpLock on the original file. However, it does not maintain a "CreateFile" connection to the file.
This means that while the SMB connection actually copies the file into the SMB cache on the server, an application such as IIS running locally on the server could still simultaneously load the file, but only one SMB connection to the same file can be served at any time. If a second access attempt via SMB is attempted while the initial connection is still active, the OS on the server will respond with an "access denied" message to the remote (requester) system.
When this "access Denied" message is relayed to the SMB requester (the client), it is communicated up to the requesting Application. LiveUpdate logs this error state as HR0x802A0033 (E_CANT_CREATE_FILE), and moves on to the next file.
Note that the changes to the SMB networking protocol in Windows Vista and Windows 2008 modify the efficiencies around how these file acceses are managed, but overall, the limitations remain constant - LiveUpdate will return an error if another client is downloading the file at the exact moment that client attempts to request the file.
Imported Document ID: TECH97610
Legacy ID:
2009111917215848
Subscribing will provide email updates when this Article is updated. Login is required.
Thanks for your feedback. Let us know if you have additional comments below. (requires login)