Bug 98935 - file rename silently fails when the original filename contains question mark
Summary: file rename silently fails when the original filename contains question mark
Status: RESOLVED FIXED
Alias: None
Product: juk
Classification: Applications
Component: general (show other bugs)
Version: 2.1.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Scott Wheeler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-09 14:27 UTC by Marcin Kasperski
Modified: 2005-02-18 05:06 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Kasperski 2005-02-09 14:27:41 UTC
Version:           2.1.1 (using KDE 3.3.1,  (3.1))
Compiler:          gcc version 3.3.5 (Debian 1:3.3.5-3)
OS:                Linux (i686) release 2.4.20-ck2

1. I have the ogg file with question mark embedded in name (in case anyone is curious: somewhere some national character was changed into question mark)

2. I edit its tags within juk to my taste.

3. I press Ctrl-R to rename the file according to the tags.

4. I am prompted the confirmation, press OK.

5. Nothing is changed.

If I rename the file (even in juk using FileName field) so the ? is removed from the name, it all works.

I am not 100% sure but it seems that if I rename many files simultaneously, it also breaks the process so the further files are not renamed even if they do not have ? problem.
Comment 1 Marcin Kasperski 2005-02-09 14:35:16 UTC
Maybe it is dupe of bug 77315 but I do not understand clearly whether it is or is not the same problem. My problem is observed on reiserfs and has nothing to do with vfat (the only common denominator is the fact that both my reading from CDDB and reported there reading from vfat decided to handle unknown win-1250 character by replacing it with ?)
Comment 2 Scott Wheeler 2005-02-18 05:06:11 UTC
Well, this is related to one of the other issues brought up in the #77315 report -- and was actually fixed there, so the fix will be in 3.4.