Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#813 / in a file search attribute causes unexpected behavior

1.2
closed-fixed
libfm (236)
5
2013-11-30
2013-11-29
Sworddragon
No

I'm using PCManFM 1.1.2 and on Tools -> "Find Files" values with a / can make troubles. Here is an example:

1. Go to /tmp.
2. On "File Name Patterns" write "/*" without the doublequotes.
3. The search result will now be "search://tmp?recursive=1&show_hidden=0&name=/*&name_ci=1".
4. On going now a directory up PCManFM thinks that the / in the attribute is a directory and will navigate to "search://tmp?recursive=1&show_hidden=0&name=/".

As we are on search:// the last ? in the string should be like a delimiter. All characters behind it should not be treated as any special operation (like thinking in this case we are in a subdirectory).

Discussion

    • milestone: --> 1.2
    • labels: --> libfm
     
  • Well, thinking we are in subdirectory is not correct at all - we can create search for multiple directories - search in /var/run,/tmp,/var/tmp for example - which one of those is search parent? Any search is an unique entity. The behavior of that 'Up' button in the search folder is corrected in current Git sources. Test it when it's possible for you and if the issue still bothers you then feel free to reopen the report.
    Thank you very much.

     
    • assigned_to: nobody --> lstranger
    • status: open --> closed-fixed