If a song with an absolute path points inside the music directory,
print only the relative part. This happens when partial songs from a
playlist file were loaded.
This fixes an inconsistency in the stored playlist subsystem: when
obtaining the list of playlists (listplaylist, listplaylistinfo), the
file names in the playlist directory are converted to UTF-8 (according
to filesystem_charset), but when saving or loading playlists, the
filesystem_charset setting was ignored.
After we've been hit by Large File Support problems several times in
the past week (which only occur on 32 bit platforms, which I don't
have), this is yet another attempt to fix the issue.
This updates the copyright header to all be the same, which is
pretty much an update of where to mail request for a copy of the GPL
and the years of the MPD project. This also puts all committers under
'The Music Player Project' umbrella. These entries should go
individually in the AUTHORS file, for consistancy.
When there are duplicate slashes in the song paths, eliminate them;
example:
/var/lib/mpd/music//foo.mp3
becomes:
/var/lib/mpd/music/foo.mp3
The slash is only detected at the border between the music_directory
and the local part.
When the user configures a music_directory with a trailing slash, it
may break playlist loading, because MPD expects a double slash. Chop
off the trailing slash.
When save_absolute_paths_in_playlists was enabled in mpd.conf, MPD
broke all playlists when manipulated using the "playlistdelete"
command. The reason was that map_directory_child_fs() was used, which
doesn't accept slashes in the file name. Use the new map_uri_fs()
function instead.
Make map_directory_child_fs() refuse the names "." and "..". This is
currently the interface where an attacker may inject a manipulated
path (through the "update" command).
The mapper library maps directory and song objects to file system
paths. With this central library, the code mixture in path.c should
be cleaned up, and we will be able to add neat features like aliasing.
