Lloyd Bryant wrote: > But share_free() is called early in share_scan(). It destroys search_table, > the file_basenames hash table, all of the shared_file entries, and > file_table. At that point, it doesn't matter what indices you've still got, > as they've got nothing to index. Until the directory scan is complete and > file_table is rebuilt, it's pretty much impossible to access any file. > > Note that without the sort, the situation was different. file_table was > rebuilt as files were scanned, becoming accessible via the index much sooner > than they do now. Of course, "sooner" is less than 3 seconds sooner (that's > the time from the end of the sort to the end of share_scan() from my 100,000 > file test).
Sure but that's 3 seconds in a pathologic case and how often does one perform a rescan. I've considered adding a way to rescan only certain paths which could decrease this time quite a lot. It makes share_scan() a bit more complicated and it might not be worth the effort. > Perhaps it would have been better to have added "browse_previous_index" and > "browse_next_index" to the shared_file structure, and then have a > "browse_first_index" global that points to the first entry. Such a linked > list could be sorted in any order without affecting anything else in the > system. Build an array based on this list, qsort it, then update the links > based on what qsort returns. We can have multiple index tables for multiple flavours of course. One that sorts by mtime, another by path, by size, by whatever. Though I'm not sure where or how you'd want to configure or use this. I don't want a configuration setting just for the sake of having another setting. If anyone in reality really wants this it can be added of course. > What about using device + inode in place of the full file path? These are > just as guaranteed to be unique (and a heck of a lot shorter: Typical ext3 > filesystem device is 64bits, and inode 32. Worst case would be 64+64, or 16 > bytes, which is still a heck of a lot shorter than > "/home/lloyd/gtk-gnutella/shared/......". This has the advantage of not > requiring a SHA1 recalc if a file is mv'ed (which changes ctime, but not > atime or mtime). I'm not so sure that device and inode number are guaranteed to persist beyond a reboot or between system upgrades. Also the inode numbers might be recycled. Also I don't see how you can use device and inode number instead of the path. How do you find those files? -- Christian ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
