Literature and Latte

When I use File>Export>Files...'d
the combination of folders/documents and their sub-documents produced some (relatively) few stranded documents, their paths too large (+260 bytes) to be copied, moved, backed up.
After the usual treatments --
shortening parent directory/folder names; deleting the doc/files by their 8.3 short name; RMDIR; even by SUBST'ing then trying these steps --
I did remove most of the documents.

However, one persists; the system returns that the folder is 'not found'.
A command-line DIR /x command does not show an 8.3 short name for the folder; DIR shows the long name.

Enabling the registry/policy's LONGPATHSENABLED did not get me access.

I'm looking at an apparently well received UNLOCKER freebie, which reportedly will also delete the folder/file:
Have folks used its abilities sucessfully, without infection?

(However I get this resolved, I will merely copy the projects #'d documents and handle them that way -- I will not simply edit them in place ... that would screw up the indexing -- or I will consider using sync.)

(Despite the signature, I am just at 1.9.8.)

I have used Unlocker. Results are mixed - sometimes it works, others, not so much. It's safe, though.

Ma ... Thank you for your reply.

It occurred to me not long after I SUBMITted my post -- esprit d'escalier -- between that and your replying ...

The backup software I use (Syncback) has the ability to MIRROR the contents of one folder/drive/whatever to another. (By 'mirror', it means obliterate whatever is in the destination folder with the precise contents of the source folder; I'm sure other backups have the ability as well.)
I defined a new folder, put nothing in it;
I mirrored the null contents of the new folder to the folder that had the too-long file name;
Voilà, the too-long-named file was gone!
(No, I wasn't taking a bath, nor the neighbors startled. )

(GONE was all I wanted: The destination folder was meant as a static structured memorial of the Scrivener project -- and this time, it was a test. I realize that there would be EXPORT overhead for it during the 'name specification' part of the routine, but maybe L&L could skip such file-pathed files.
(Aside from the difficulty of noticing such files and paths post hoc, I could load Null Folder with replacement files, with shortened names, and perhaps shorten the path, before the MIRRORing.)

I don't know that enabling the LongPaths enabled the software, but Hey! It worked. (I'm keeping the backup program's 'profile' and 'Null Folder' for next time.)

Thank you again; I may look at UNLOCKER, put it in my toolbox since it comes so highly recommended!

I do appreciate the quick reply.