| Summary: | sometimes "[]" should not be treated as wildcard | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | LuRan <hephooey_dev> |
| Component: | general | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | aironmail, blue.american, cyberbeat, des, dmoyne, guido-kdebugs, hernandes, holster, jens-bugs.kde.org, lecit, lofi, lovewilliam, matthias.pospiech, michel.hermier, nick.steeves, sum_of_the_total, thiago |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
LuRan
2005-06-10 15:40:40 UTC
Confirmed, trunk 414026. *** Bug 107673 has been marked as a duplicate of this bug. *** *** Bug 108130 has been marked as a duplicate of this bug. *** Raising severity. *** Bug 109757 has been marked as a duplicate of this bug. *** From what I've seen in Bug 109757, Xine and noatun properly get the file URL. Isn't it strange that they work ok? @ #6: Not really. See bug number 108130 (which is a duplicate of this one, see link in comment #3) which explains it quite well. It seems to depend on whether you left-click on the file to open it with the default app or whether you right-click and choose one from the options. ah, you're right. I double checked Xine and noatun behavior, and it turns out that they were being sent the directory, but had cached the right-click file in their playlist, and found an avi to play in this way. I hadn't noticed that they were always playing the same avi, no matter which file I clicked on. I was left-clicking, but didn't realize that the playlists had cached a file from an earlier right-click. Today I encountered a dir which ended with the "?" character. It behaved the same as the directory in bug 107673. Having the same problem. Moreover, if a directory has [ or ] in its name, konqueror doesn't want to enter it. #10: I cannot confirm this. Over here, the problem only happens if the file- or directory-name contains any of "[", "?", or "*". If it doesn't contain any of those but does contain a "]", the bug doesn't show. (i.e. I can enter the directory/open the file.) I did this in konq_mainwindow.cc:
@@ -423,7 +423,7 @@
}
QString fileName = path.mid( lastSlash + 1 );
QString testPath = path.left( lastSlash + 1 );
- if ( ( fileName.find( '*' ) != -1 || fileName.find( '[' ) != -1 || fileName.find( '?' ) != -1 )
+ if ( ( fileName.find( '*' ) != -1 || fileName.find( '?' ) != -1 )
&& ( !url.isLocalFile() || QFile::exists( testPath ) ) )
{
nameFilter = fileName;
and now I have no problem with file with "[]" in its name. I don't think it's a fix, just a dirty hack
*** Bug 109930 has been marked as a duplicate of this bug. *** " ------- Additional Comment #10 From Gleb Litvjak 2005-07-30 18:24 ------- Having the same problem. Moreover, if a directory has [ or ] in its name, konqueror doesn't want to enter it. " I confirm! I have a lot of directories with the [ and ] characters and since KDE/Konqueror 3.4.2, Konqueror doesn't want to enter those directories. Nautilus does it right. Ugh* Yup, I can confirm too. Btw, opening via "Open with" works fine. *** Bug 110001 has been marked as a duplicate of this bug. *** *** Bug 110012 has been marked as a duplicate of this bug. *** *** Bug 110050 has been marked as a duplicate of this bug. *** Confirming the bug here. I just noticed that wildcards in the location bar don't work at all anymore in any of the filemanager views, too! :-( :-( :-( (Example: ~/*.mp3 in detailed list view) Is that related, perhaps? If not, I'll open another bug. SVN commit 443311 by pletourn:
If a fileName exits, don't try to detect a name filter
BUG:110227
BUG:107170
M +1 -1 konq_mainwindow.cc
--- branches/KDE/3.4/kdebase/konqueror/konq_mainwindow.cc #443310:443311
@@ -428,7 +428,7 @@
QString fileName = path.mid( lastSlash + 1 );
QString testPath = path.left( lastSlash + 1 );
if ( ( fileName.find( '*' ) != -1 || fileName.find( '[' ) != -1 || fileName.find( '?' ) != -1 )
- && ( !url.isLocalFile() || QFile::exists( testPath ) ) )
+ && ( !url.isLocalFile() || QFile::exists( testPath ) ) && !KIO::NetAccess::exists( url, true ) )
{
nameFilter = fileName;
url.setFileName( QString::null );
Is there any chance that this will be backported to KDE-3.4.2? I encountered a compilation error after applying this patch to kdebase-3.4.2 in the NetAccess bit. #include <kprocess.h> +#include <kio/netaccess.h> #include <kio/scheduler.h> in the same file will make it compile. Thanks for the tip Michael. From what I've seen so far, this fix looks great. :-) *** Bug 110277 has been marked as a duplicate of this bug. *** *** Bug 110287 has been marked as a duplicate of this bug. *** Can someone confirm the fix for KDE 3.4.2? We'll have a KDE 3.4.3 release and I'd like to backport. I confirm, but don't bother, it already is backported. :-) does it fix {} these brackets too?
> does it fix {} these brackets too?
Yes, I've just tested.
I don't think this was backported for 3.4.2 (as it says in comment #28) I still have the problem of not being able to enter directories with [] characters in the name (comment #10). I don't know if it's fixed in branch so I'll leave closed (for now). Let me rephrase comment #27: "can someone confirm the fix works for KDE 3.4.2? I want to add it to KDE 3.4.3", to which it was answered: "yes, it works, it was backported". So, the fix isn't in KDE 3.4.2 because it was released before the fix happened. You have to either patch it or wait for KDE 3.4.3. *** Bug 110373 has been marked as a duplicate of this bug. *** *** Bug 111104 has been marked as a duplicate of this bug. *** *** Bug 113683 has been marked as a duplicate of this bug. *** *** Bug 115301 has been marked as a duplicate of this bug. *** |