Exporting a document to .txt caused an issue

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

image

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.

Any ideas ?

Can you drag inside an empty folder and delete. Other thing look at permissions for folder might be only modifiable by admin account

Thanks ; but I tried all that. None of which worked.

image

Does it persist per reboot. If does then consider removal when in safe mode. Weird

Fixed it.

Ran Command prompt as administrator, then pasted → rd /s "\?\ ← followed by the folder’s path.

That now only leaves the question regarding how it got to happen in the first place.
Avoid documents titles with “/” in them I suppose.

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.

1 Like

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

Glad you got this sorted out, Vincent_Vincent.

This is not an unusual problem in Windows.

For those not wanting to watch the video you posted, and/or who need a written summary of the process to solve this problem, here is how to get rid of this problem:

  1. Press Windows Key

  2. Enter the text
    CMD

  3. Enter the text
    rd /s "\?\

  4. Get file location/path by going into File Explorer and double-clicking on folder which will not delete, and then click in Browser search bar.

  5. Then copy and paste file path after rd /s "\?\

  6. Press/ Click
    Enter

  7. Choose the option
    Y

  8. Press/Click
    Enter, and folder will be deleted.

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.