Fix problems with 7.3 SMB2 support

The PMR noted for this RFE encountered a specific problem related to the SMB2 request SET_INFO with an information class of FILE_ALLOCATION which was not supported by IBM i NetServer when IBM i 7.3 GA'ed. The development team has provided PTF MF63402 in IBM i 7.3 which will default to indicate this request was successful. A switch is provided in the PTF to change the behavior back to the release default. The text of the correction from the PTF coverletter is included below in this response.
NOTE: This same support was included in the PTFs to add SMB2 support for IBM i NetServer in 7.2.

We understand that IBM i NetServer may not operate the same as other servers and we strive to transition to new versions as seamlessly as possible.

As stated in other posts, this RFE is too general for the development team to address the request in a specific manner. Previous requests for additional information have received no response. For future requests please provide a specific request that can be addressed. As we have addressed the problem from the PMR, we are marking this RFE as delivered. Please open a new RFE for future enhancements for SMB2 support in IBM i NetServer.

Correction text from MF63402
----------------------------------------
IBM i NetServer has added limited support for the following
attribute classes to improve compatibility with SMB2 clients:

+ FileFsFullSizeInformation query information class
+ FileAllocationInformation set information class

Attempts to use either information class against NetServer prior
to this PTF would fail with STATUS_NOT_SUPPORTED (0xC00000BB).
The server behavior with this PTF applied changes as follows:

-- Client queries for FileFsFullSizeInformation will succeed and
return correct information for the file system.

-- Setting FileAllocationInformation on a file will return
success, but the operation will have no effect on the disk
allocation size of the file. Setting the
FileAllocationInformation is a transient operation that only
lasts until close, at which time the allocation size is expected
to truncate to the actual data size of the file. The IBM i file
system interfaces do no allow directly modifying the disk
allocation for stream file objects. Clients wanting to set the
permanent data size of the file should either write a single
byte at the target size offset in the file or set the
FileEndOfFileInformation directly.

If the new behavior for FileAllocationInformation causes
problems in a customer environment, the behavior can be altered
by calling the following commands.

Return STATUS_NOT_SUPPORTED for FileAllocationInformation:
CALL QZLSMAINT PARM('40' '1' '0x200')

Re-enable the PTF default behavior for
FileAllocationInformation:
CALL QZLSMAINT PARM('40' '2' '0x200')

We are experiencing similar problems with SMBv2 enabled on the IFS.

In addition to the issues detailed in the IBM docs, in our testing we have found that browsing shares on the IFS that contain large number of files from a Windows 7 PC causes excessive network traffic and excessive processor usage on the IBM i. It looks severe enough to be dangerous to enable SMBv2 if you have PCs running Windows 7.

I don't understand exactly what the IBM System Developer means when he says in option 2 "Netserver would not actually change anything". Presumeably the action (whether rename or move/copy etc) would be done but NetServer just doesn't confirm its successful. So pretty much as now?

If thats the case, providing that switch would allow us to enable SMBv2, which we are being asked to do for security pruposes. Please can you let us know the timescale. As its a high focus security issue, we need a solution asap.

I think IBM should highlight the potential dangers over loading system resouces if SMBv2 is enabled with Windows 7 in thier documents.

Due to an error in processing, this RFE was incorrectly placed into status "Information Provided". I am now changing it back to "Need More Information" since we need the Submitter to respond to the previous Comment, which asked which of 2 options is preferred for addressing this RFE.

The development team has been investigating through the related PMR for this RFE. This RFE mentions the change notify requests, however the RFE title is very general. IBM i NetServer does not support the change notify requests sent by the client. IBM i NetServer correctly returns to the client that the change notify request is not supported as it did for the previous releases. There are very few applications that do not work because of it, but it is important to note this is not a change from NetServer support for SMB1.

Through traces collected from the customer it was discovered IBM i NetServer returns a 'function not supported' response to the SMB2 request SET_INFO with an information class of FILE_ALLOCATION_INFORMATION and this response causes the user's application to fail which is the request I will be addressing here.

The object design on the IBM i does not allow NetServer to properly support this request in that when the file is closed the file allocation is truncated back to
the end of the data. Users (including system code) are only allowed to control the size of a stream file by setting the data size (EOF) and the system has no
way to know where the actual end of data is once EOF has been changed so we cannot change the EOF when the file is closed. This results in extra (bad)
data in the file.

To that end we have basically 2 options.
1. Return STATUS_NOT_SUPPORTED for this request which is what we are currently doing.
2. Provide a switch where users can decide to allow NetServer to claim the request was successful, but NetServer will not actually change anything on the object.
Note that an application that tries to verifiy the allocation size may not like this but we've not seen any application actually check.

As stated above, the RFE title is too general to address in a specific manner. Based on the information gathered in relation to the PMR, we would like to know if
option 2 above will provide the support requested.

The development team is investigating.