On Mon, May 16, 2005 at 07:39:20PM +0200, Christophe Fergeau wrote: > Le lundi 16 mai 2005 ? 13:00 -0400, Stefan Monnier a ?crit : > > > I think the only *safe* moment when we can remove an entry from the database > > is when the two conditions are met: > > 1 - `lstat' says the file doesn't exist. > > 2 - the directory in which the file should reside does exist. > > So it's ok to screw people mounting /home/music via nfs and storing > their music there in a hierarchy like Artist/Album ? Agreed, this'd suck for me :) > > All in all, I'd rather *never* auto-remove entries from the database. > > Instead we should introduce a flag "missing" and grey-out the songs which > > are "missing". And add a command to flush-out "missing" entries. > > What 0.9 is supposed to do it: > * store the mount point where each song is located > * before removing a file, check if the mount point it was in is still > available > * if it's there and the song isn't, remove the song > * if it's not there, remove the song if it hasn't been available in x > days, with x being configurable in gconf > > If it doesn't work, then a bug was added at some point and it should be > fixed. A nifty feature here would be a automatic 'reconnect', where if a song disappears, RB can try to find it again. A lot of times I'll use musicbrainz to re-organize my collection, and minor changes in filename will occur. Something even simliar to the windows 'browse for missing file' might work. alan -- Alan <alan ufies org> - http://arcterex.net -------------------------------------------------------------------- "Backups are for people who don't pray." -- big Mike
Attachment:
pgpLUMewYij9B.pgp
Description: PGP signature