level 261 findfirst

Steve French smfltc at us.ibm.com
Tue Nov 9 21:34:24 GMT 2004

Trying some experiments today with level 261 of SMB trans2 FindFirst
today (to return inode numbers when no CIFS Unix extensions) I noticed
that Samba 3 (at least current code) and Windows XP seem ok (Samba sends
a 4 byte smaller response due to padding but it is probably harmless). 
Win2K doesn't support it unfortunately.  At
negprot/sesssetup/tconX/QFSInfo time do you think there is any easy way
to tell that the infolevels that are aware of inodes (e.g. 261) are

Also looks like Samba 4 header is wrong (unless I am misreading
something).  The UniqueId/InodeNumber is at offset 0x48 from the start
of a search entry (for level 261), and the name itself at offset 0x50,
yet smb-interfaces.h shows struct full_directory_info 

What I see is 
u32 NextEntryOffset
u32 Index (seems to be always zero)
u64 create time
u64 last access time
u64 last write time
u64 change time
u64 end of file
u64 allocation size of file
u32 file attributes
u32 name length
u32 ea length?
u32 pad?
u64 inode number (unique file id, Note that Samba 3 makes it from 
	dev number with low 32 bits of inode number, hope that is 
	unique enough on 64 bit platforms since i_ino is unsigned long)
char[] FileName

smb-interfaces shows 

        struct {
                uint32_t file_index;
                NTTIME create_time;
                NTTIME access_time;
                NTTIME write_time;
                NTTIME change_time;
                uint64_t size;
                uint64_t alloc_size;
                uint32_t attrib;
                uint32_t ea_size;
                uint64_t file_id;
                WIRE_STRING name;
        } id_full_directory_info;

Isn't that wrong or is there some magic that fixes the string len up and
puts it earlier in the frame?

More information about the samba-technical mailing list