Your message dated Sun, 25 Mar 2018 15:24:01 +0100 with message-id <029d7f15-4505-0e4a-5b0d-f608724fd...@debian.org> and subject line Re: easytag: Tag and File Name scan moves files to "~" instead of /home/$user has caused the Debian Bug report #620084, regarding easytag: Tag and File Name scan moves files to "~" instead of /home/$user to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 620084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620084 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: easytag Version: 2.1.6-1 Severity: normal EasyTAGs "Tag and File Name scan" is possibly not working properly. If I change the target filename to a path including a tilde (~) in order to move the files to a subdirectory in my home directory, the example output correctly translates the target directory to /home/$user/targetdir. After actually making EasyTAG rename the files, it does not move them to /home/$user/targetdir, instead it creates a directory named "~" in targetpath, so that the files finally are located in targetpath/~/targetpath. I guess this behavior is not intendet. Reproducible with every file. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (700, 'stable'), (500, 'squeeze-updates') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages easytag depends on: ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libflac8 1.2.1-2+b1 Free Lossless Audio Codec - runtim ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2.1 FreeType 2 font engine, shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libid3-3.8.3c2a 3.8.3-13 A library for manipulating ID3v1 a ii libid3tag0 0.15.1b-10 ID3 tag reading library from the M ii libogg0 1.2.0~dfsg-1 Ogg bitstream library ii libpango1.0-0 1.28.3-1+squeeze2 Layout and rendering of internatio ii libspeex1 1.2~rc1-1 The Speex codec runtime library ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libvorbis0a 1.3.1-1 The Vorbis General Audio Compressi ii libvorbisfile3 1.3.1-1 The Vorbis General Audio Compressi ii libwavpack1 4.60.1-1 an audio codec (lossy and lossless ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime easytag recommends no packages. easytag suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---Hi, On Tue, 29 Mar 2011 23:47:50 +0200 Thomas Schmitz <schmitz.tho...@gmail.com> wrote: > Package: easytag > Version: 2.1.6-1 > Severity: normal > > EasyTAGs "Tag and File Name scan" is possibly not working properly. If I > change the target filename to a path including a tilde (~) in order to > move the files to a subdirectory in my home directory, the example > output correctly translates the target directory to /home/$user/targetdir. > > After actually making EasyTAG rename the files, it does not move them > to /home/$user/targetdir, instead it creates a directory named "~" in > targetpath, so that the files finally are located in targetpath/~/targetpath. > > I guess this behavior is not intendet. I believe this is the intended behavior. It is not easytag's responsibility to expand "~" into the user's home directory. The vast majority of applications do not do this - only the shell does. In new versions of easytag, easytag will print an example filename in the scanner dialog box which highlights that "~" will not be expanded. Hopefully this will mean that users will not accidentally rename their files to names they did not intend to. Closing the bug. Thanks, Jamessignature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers