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,
James
signature.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
