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

Bug #1284363 reported by Fernando De Freitas
72
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Files
Fix Released
High
Jeremy Wootten

Bug Description

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.

Tags: ntfs

Related branches

Revision history for this message
Fernando De Freitas (fdefreitas) wrote :
description: updated
Revision history for this message
DimitrisC (dimitrisucy) wrote :

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.

Changed in pantheon-files:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Paul Phillips (paul-gs-phillips) wrote :

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...

Revision history for this message
Ben van Setten (ben-launchpad) wrote :

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.

Revision history for this message
Charles Kramer (cvkramer) wrote :

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.

Revision history for this message
Jeremy Wootten (jeremywootten) wrote :

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.

Revision history for this message
Jeremy Wootten (jeremywootten) wrote :

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

Changed in pantheon-files:
assignee: nobody → Jeremy Wootten (jeremywootten)
status: Confirmed → In Progress
Changed in pantheon-files:
status: In Progress → Fix Committed
milestone: none → loki-alpha1
Changed in pantheon-files:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.