LW has a brittle database of shared files that can not 'remember' volumes that are temporally offline when LM restarts ...

... this fragile approach to the persistence of the database for shared files causes a huge waste of time (20-30 hours!) for both the user & the cpu & other users of the network (not to mention the unnecessary wear & tear on the drives) when 10,000 files must be reindexed from scratch after a volume is re-attatched.

please allow the user to (explicitly) instruct LW to retain state info for the shared info database so that no reindexing is required when LW restarts without some of the shared volumes being attached.

surely spotlight & especially time machine - on the mac - already do most of the heavy lifting required to maintain a virtual file system.

(yes, i realize that cross-platform functionality in the LM is an important goal; but surely this kind of forking is an acceptable variance since it does not effect the actual gnutella protocol itself).

indeed with a proper session manager, it should be possible to load a variety of different shared files databases into LW (just as disk images can be used to load different virtual machine states into a hypervisor such as vmware). Even simple archiving of the database might a good enough work-around, as compared to a full virtual file system like time machine. However, perhaps the best approach is an intermediate one (between just multiple dumb archives or a full-fledged virtual file system): use a container that is optimized for structured storage: lotus & apple devised Bento for this task in the 90's, and ibm also used it for opendoc; however in this decade, sun's ZFS does a snapshot feature which might also be a useful intermediate solution (and ZFS is built-in to osx snow leopard).

bottom line is that a memory feature for temporally unattached drives would make limewire much more manageable.

anyone else being driven crazy by losing 24 hours of machine time while the shared index is being rebuilt?