[Thunar-dev] ThunarVfsInfo: Bug in thunar_vfs_info_new_for_path?

[Benedikt Meurer]

Jannis Pohlmann wrote:
>>>HORRAY! No idea how you found out that *this* caused the problem.
>>>Impressive, really.
>>
>>
>>On a linux box:
>>
>>grep LARGEFILE /usr/include/sys/*.h
>>[...]
>>/usr/include/sys/types.h:#if defined __USE_LARGEFILE64 && !defined
>>__ino64_t_defined
>>/usr/include/sys/types.h:#if defined __USE_LARGEFILE64 && !defined
>>__off64_t_defined
>>[...]
>>
>>*SCREAM*
>>
>>open /usr/include/sys/types.h and recognize that ino_t has no fixed size
>>on Linux/i386, but depends on whether largefile support is active.
>>Thunar is compiled with largefile support, your program wasn't, so for
>>your program the compiler got the wrong offset for path in ThunarVfsInfo
>>and *BOOM*.
>>
>>I'll commit a workaround.
> 
> Holy shit. Good to have you, hehe.

Ok, I decided to drop the inode field from the ThunarVfsInfo struct, as
it isn't used within Thunar, it was only used for the comparison in
thunar_vfs_info_matches(), but it happens seldomly that a file is
replaced and all attributes besides the inode are the same as the old
file, maybe once in 1.000.000 years, unless somebody prepares a program
to do exactly this. But even in this case, inotify/kqueue/imon will
report this change.

This saves another 8 byte per file, or 8 kB (notice the lower-case "k"!)
when viewing a folder with ~1000 files, not a biggy, but hey it's your
memory. ;-)

Benedikt