The hint of OS/2 clients about the expected final file size is ignored by smbd in the LANMAN2 protocol level. This may decrease I/O speed and increase file system fragmentation.
Created attachment 1910 [details] Potential fix for the above problem I think I already fixed the problem. It works for me for some months so far. However, someone should have a look on the patch. The code is maily taken from the similar functionality of the corresponding NTTRANS call.
Created attachment 1911 [details] Replacement patch. I think this patch may be closer to the nttrans code. Can you test this out please and see if it matches what you observe. Thanks, Jeremy.
Created attachment 1912 [details] Initial EA fix First: I think you are mainly right. The code seems to work as expected. (Once I got a core dump, but I cannot reproduce this. Maybe it is not related at all.) However, I unawares fixed another issue concerning the initial EAs immediately after this code: The line if (total_data && smb_action == FILE_WAS_CREATED) { is not right in my opinion. The OS/2 API docs say about the EA structures at DosOpen: "This parameter is only used to specify extended attributes (EAs) when creating a new file, replacing an existing file, or truncating an existing file. When opening existing files, it should be set to null." The code line above only captures the case when the file was created. I found another minor memory leak today. When the client passes an FEA structure and the file is not created or replaced (most likely because of OPEN_ACTION_OPEN_IF_EXISTS), the memory block allocated in line 822 is never released. I think we sholud always free the temporary storage for the extended attributes (Assuming that talloc_destroy(NULL) is a no-op). Furthermore, we should check for ea_list rather than total_data if we want to know wether the trans2open call has extended attributes, isn't it?