mpd has long used mtime to detect changes for updates. Unfortunately, some popular tag editors default to not changing (or resetting) mtime on files they modify; so mtime isn't highly trustable.
Since ctime is not changeable with standard library functions, it can be a better candidate for detecting changes to music files. This also means changing ownership/permissions of a file will cause mpd to rescan that file. However, normal atime (access time) changes do NOT update ctime; so playing a song shouldn't cause ctime to change. Would changing mpd to use ctime instead of mtime cause undue stress for anybody on slightly odd[1] filesystems? At worse this will cause files to be needlessly rescanned during updates; but if there's software running the the background that happens to change ctimes willy-nilly; then I don't consider it to be the problem of mpd. Taking longer to update because it is overscanning due to ctime is less of a user-visible problem to me than underscanning due to mtime... More info about this stuff available here: http://en.wikipedia.org/wiki/MAC_times [1] meaning not-fully POSIX compliant filesystems like AFS, FAT32, FUSE-whatever, NFS, NTFS, etc... Some of these weird FSes have multiple implementations/versions that can have different ctime semantics, too. -- Eric Wong ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
