Environment
Novell Open Enterprise Server 11 (OES 11) Linux Support Pack
2
Situation
MAC clients are unable to copy a file larger than 4 gig to an OES
11 SP2 servers NSS volume that has plenty of free space.
The MAC client reports an error similar to this:
"Can't be copied because it is too large for the volume's format"
Windows clients are able to copy a 4 gig+ sized file to the same CIFS OES servers NSS volume.
NSS volumes to not have a 4 gig limit.
DOS volumes do have a 4 gig limit.
The same MAC client can copy the same large file to a Windows server over CIFS.
The MAC client reports an error similar to this:
"Can't be copied because it is too large for the volume's format"
Windows clients are able to copy a 4 gig+ sized file to the same CIFS OES servers NSS volume.
NSS volumes to not have a 4 gig limit.
DOS volumes do have a 4 gig limit.
The same MAC client can copy the same large file to a Windows server over CIFS.
Resolution
There is nothing to change on the OES CIFS server to bring it into compliance as it is
already following Microsoft's File System Information Classes
specifications.
This issue has been reported to engineering anyway to see if there is anything that can be done to work around the MAC defect.
In the meantime you can contact Apple and ask if they are aware that they appear to be in violation of Microsoft's File System Information Classes specifications for FileSystemName.
This issue has been reported to engineering anyway to see if there is anything that can be done to work around the MAC defect.
In the meantime you can contact Apple and ask if they are aware that they appear to be in violation of Microsoft's File System Information Classes specifications for FileSystemName.
Cause
The reason that the MAC fails to copy the large file over CIFS to
the OES servers NSS volume is because at the time of the writing of
this TID the MAC client is apparently incorrectly using the
FileSystemName variable to apply DOS limitations to the file
copy.
At this link Microsoft defines it's File System Information Classes and how they should be used.
https://msdn.microsoft.com/en-us/library/cc232101.aspx
In section 2.5.1 referring to the FileSystemName(variable) which the OES CIFS server returns as FAT for its NSS volumes, it says:
"FileSystemName (variable):
A variable-length Unicode field containing the name of the file system.
This field is not null-terminated and MUST be handled as a sequence of FileSystemNameLength bytes.
This field is intended to be informative only.
A client SHOULD NOT infer file system type specific behavior from this field.<136>
Following the link labeled <136> at the end of the last statement takes you to a table of valid values for the FileSystemName (variable).
As you can see FAT by definition is a valid value for this variable in every case.
This information from Microsoft defining how File System Control Codes MUST be handled says that the FileSystemName can contain FAT.
In addition it says that , "A client SHOULD NOT infer file system type specific behavior from this field."
That means that the OES CIFS implementation is within the Microsoft defined specifications.
The error reported on the MAC about the volumes format implies that it is using the FileSystemName to "infer file system type behavior" in violation of the specs.
In a LAN trace captured during a failing copy from a MAC to the OES CIFS server it was observed that the OES CIFS server replied to all QUERY_FS_INFO requests with data indicating that the server's file system had plenty of room to receive the file.
Unfortunately the MAC has already failed, apparently based on the FileSystemName variable containing "FAT" resulting in the can't be copied error based on the file being to large for the volume's format.
The reason that the same MAC client can copy a file larger than 4 gig to a Windows server is because the Windows server returns NTFS in the FileSystemName variable. If the MAC client incorrectly inferred "file system type behavior" for the NTFS file system type it would not limit the file copy.
At this link Microsoft defines it's File System Information Classes and how they should be used.
https://msdn.microsoft.com/en-us/library/cc232101.aspx
In section 2.5.1 referring to the FileSystemName(variable) which the OES CIFS server returns as FAT for its NSS volumes, it says:
"FileSystemName (variable):
A variable-length Unicode field containing the name of the file system.
This field is not null-terminated and MUST be handled as a sequence of FileSystemNameLength bytes.
This field is intended to be informative only.
A client SHOULD NOT infer file system type specific behavior from this field.<136>
Following the link labeled <136> at the end of the last statement takes you to a table of valid values for the FileSystemName (variable).
As you can see FAT by definition is a valid value for this variable in every case.
This information from Microsoft defining how File System Control Codes MUST be handled says that the FileSystemName can contain FAT.
In addition it says that , "A client SHOULD NOT infer file system type specific behavior from this field."
That means that the OES CIFS implementation is within the Microsoft defined specifications.
The error reported on the MAC about the volumes format implies that it is using the FileSystemName to "infer file system type behavior" in violation of the specs.
In a LAN trace captured during a failing copy from a MAC to the OES CIFS server it was observed that the OES CIFS server replied to all QUERY_FS_INFO requests with data indicating that the server's file system had plenty of room to receive the file.
Unfortunately the MAC has already failed, apparently based on the FileSystemName variable containing "FAT" resulting in the can't be copied error based on the file being to large for the volume's format.
The reason that the same MAC client can copy a file larger than 4 gig to a Windows server is because the Windows server returns NTFS in the FileSystemName variable. If the MAC client incorrectly inferred "file system type behavior" for the NTFS file system type it would not limit the file copy.