Bug 3790 - smbd ignores initial file size on TRANS2OPEN call
smbd ignores initial file size on TRANS2OPEN call
Status: ASSIGNED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.23
x86 All
: P3 normal
: none
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-19 10:46 UTC by Marcel Müller
Modified: 2006-05-20 07:58 UTC (History)
0 users

See Also:


Attachments
Potential fix for the above problem (1.28 KB, patch)
2006-05-19 10:49 UTC, Marcel Müller
no flags Details
Replacement patch. (1.72 KB, patch)
2006-05-19 19:19 UTC, Jeremy Allison
no flags Details
Initial EA fix (2.45 KB, patch)
2006-05-20 07:58 UTC, Marcel Müller
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel Müller 2006-05-19 10:46:00 UTC
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.
Comment 1 Marcel Müller 2006-05-19 10:49:39 UTC
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.
Comment 2 Jeremy Allison 2006-05-19 19:19:54 UTC
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.
Comment 3 Marcel Müller 2006-05-20 07:58:44 UTC
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?