"This folder does not exist." message when going up on NTFS filesystem

[Fernando De Freitas]

When going "Up" inside a folder tree deeper than 1, i.e /firstLevel/secondLevel/... i get the message "This folder does not exist." as I especify in the summary and as is pictured in the attached screenshot.

This happens only on NTFS filesystems. When i'm using ext4 going "Up" works correctly.

It's clear that said folder of course exists, i was standing inside a subfolder of it, but i get that error.

Excuse me if i'm not following correct etiquette for bug reporting, this is my first bug report.

If you need extra information or something please let me know.

Thanks.

[DimitrisC (dimitrisucy)]

I have the same bug when I mount a Windows Samba Share and try to navigate the folders. The first level is shown correctly as a windows share. When I click on any folder then the tab changes to "this folder does not exists".

This bug does not affect functionality in any way as far as I can tell.

[Paul Phillips (paul-gs-phillips)]

Some additional notes that might help...

I find this behaviour only occurs when I select a directory from the top "go to ..." bar that has spaces in the directory name. Typically I use this bar to navigate "up" as mentioned in previous posts. But also (curiously) it occurs if I select the directory I'm already in.

It works find when I select a directory that has no spaces in it.

When the error is displayed, it appears to be including %20 wherever there is a space... so for example:

"This folder does not exist
The folder "blah%20-%20blah%20blah%20blah" can't be found"

There's an icon displayed to allow me to create this folder if I wish.

The next curious thing is that when I select the same "%20"-ified directory name again... it adds "%25" to the front of every "%20"

...so the above example becomes:
"blah%2520-%2520blah%2520blah%2520blah"

Additional selections add a further "25" to the front of each "20"...

Don't know if that's of any help...

[Ben van Setten (ben-launchpad)]

This happens also using SSH (SFTP) logins (possibly all file system paths over gvfs).

When the user clicks an item in the breadcrumbs bar, the current path gets an URL escaped value, probably because in the application the escaping function is called one time too much for these particular uri's. While i was trying to find out where, i found another bug related to this one:

In /libwidgets/LocationBar.vala line 548 ...

newpath = newpath.replace("ssh:", "sftp:");

... should find the match only in the beginning of the string (sth like '/^ssh:/i'). Currently if you have 'ssh:' somewhere in a folder name, it will be replaced by 'sftp:' in the file manager.

[Charles Kramer (cvkramer)]

I don't get the blah%20blah when inside a folder and trying to navigate with the bar. Perhaps this was fixed in an update... hopefully this is more helpful than non.

[Jeremy Wootten (jeremywootten)]

Alt-Up will not navigate higher than share level on Samba because the GLib.File function get_parent () returns null in that case. It would be possible to fix that by simply truncating the path string appropriately and attempting to navigate to that path without testing its existence/accessibility.

[Jeremy Wootten (jeremywootten)]

LocationBar is currently undergoing a significant re-write which will hopefully fix many of these issues