Little issue here : I exported a document and a sub-document from a project as plain text files (.txt).
Thing is, my root document’s title had a “/” in it. “Mary goes shopping / Mary meets Frank”
So, and which I didn’t think of before hand, that created a sub folder.
I now have a folder named “Mary goes shopping” with a sub-folder inside it, named “Mary meets Frank”, with the .txt files inside “Mary meets Frank”.
Here is the thing : despite the folder showing up on my desktop, despite being able to move it elsewhere on my computer, or copy/paste it anywhere, I just can’t delete it anymore (!!)
I right click on it, choose delete, but yet I keep getting a message saying the folder is no longer in its specified location.
I tried to force delete it using cmd, same result.
I was able to delete the files themselves, but not “Mary meets Frank” that had them inside it.
So I am now stuck with this empty folder/folder.
(It is like if the sub-folder never got written to the registry or wherever it should have been given an ID.)
It is not a huge deal, that folder actually occupies 0 bites, but I don’t really like having trash lying around.
Try to rename the folder, removing spaces and other suspicious characters, before deleting it. If Windows won’t let you rename it, I don’t know what else to try. You may have to do it in Terminal/Console.
It is understandable how an export process that creates a filename on disk from a Scrivener document could end up creating a subfolder if a slash is part of the document name – but it shouldn’t actually happen. Maybe not a bug, exactly, but a condition that could have been accounted for, same as how characters that are illegal in filenames are substituted during an export.
It is fixed now.
But there was simply nothing at all I could do before that.
No rename. No nothing. (I could move it around, but that’s it. Any attempt at modifying it in any way just kept failing.)
I even tried creating a new folder elsewhere with the exact same name (copy/pasted the name), then moving the faulty one to its location. And the other way around too. (In hope that the two folders would merge ; the problematic one, with luck, inheriting the correct one’s attributes.) But all I managed to achieve by doing that was to have two folders with the exact same name in the same location. (Which, of course, should technically be impossible.)
Vincent, this is entirely normal, and it happens on any operating system – on Unix/Linux just as easily as in Windows.
The problem is that the specious character really has become part of the filename. So you can only manipulate it by textual means by including that character or a wildcard matching it, as you found.
There are other ways to do the necessary, but they get sharply technical.
How that character got in there is the thing the Scrivener team may want to look into. It’s possible for example that you typed it inadvertently. Thus a cleaning step on a user-entered path would be an easy way to avoid the possibility.
In an internet age where false paths can cause even more serious trouble, it’s de riguer to always clean user input before activities may use it, for any possibly needed exclusions…
So a nice cleanup routine would be nice to be applied wherever it would be helpful, throughout Scrivener.