Is there a reference to the file numbers within Scrivener?

Using Scrivener on windows, I have saved my file in dropbox.
then using a portable android tablet I can go to the Docs folder, open up an rtf file and continue writing/editing. All this works fine.
The problem is all the files are saved as a simple number (such as 137.rtf) So I do not know which file I need to open. Is there anyway on Scrivener (for wndows) to find out this file number for a specific piece of text?

You should not edit those files outside Scrivener, as it will mess up the whole project as the files within the project that put it all together will not know anything about what you have done and won’t be able to find the newly entered text, and the whole project may well end up corrupted and unopenable.

Check the Windows forums on advice how to work with external editors, but don’t mess with the project internal RTFs.

There is a reference, if you open the .scrivx file in a text editor. However as Mark points out, this is not so you can edit Scrivener projects without Scrivener. The format is self-descriptive and open only as a last resort. If for some reason you’re in the field and you lose access to Scrivener or whatever, you could pull your data out in an emergency—or say in thirty years if Scrivener is no longer around, you’d be able to salvage the data from an old archive. It’s a safety net for you.

I have been looking at articles and videos. On the Mac version, it is all sorted, but this seems the best way to do it on the Windows version. I have tried it a few times with no problems. I just don’t mess with the title.
If there’s any other way to write on an android device and use Scrivener of organising and editing, (Without just cut and pasting) then I’d love to hear about it.

Here’s an article
Look down to the comment by Андрей Воскресенский
This is exactly what she proposes, but makes no comment how to find the file number.

Simplenote is now available for Android.

(Edit: sorry - just seen you’re on Windows).

Well, if you wish to go on doing that it is your prerogative, but as I say the format is not designed to be used that way and we cannot support using it that way. In some places we use proprietary RTF codes that could become mangled or lost in other word processors, there are also sideboard files with notation and linking that will get indirectly damaged by losing their place and the search index will gradually grow to no longer represent your project.

The best way to work on pieces of your project without Scrivener is import/export or copy and paste instead of import. This is how I used to work all of the time as a matter of fact. I would sort my exported folder by modification date and copy and paste whatever had changed back into Scrivener when I got back home. That is basically all the Mac version does, it just automates the export/import process.

Of course Scrivener should discourage external editing of its files. But this should not preclude an ability within Scrivener to operate on its files by number.

My documents interconnect through Scrivener Links, which I create by building a self-link atop each document, and copying it where needed. The self-link is created via AutoHotkey. Absent the ability to capture a document’s file number, I obtain it by creating a snapshot, sorting the snapshot folder, parsing the filename, and ultimately deleting the snapshot file. Thus I end up altering Scrivener’s files in Windows to obtain information that would be available within Scrivener, were users trusted not to misuse it.

Also, at 7300+ documents, Search is not usable in my project. The application simply freezes up, while the entire project is reindexed. Fortunately, Windows 8.1 indexes continually; its Search is progressive and instantaneous. But the results show as files such as 3421.rtf, files which I’d prefer of course to view in Scrivener, but which will open instead in LibreOffice. Inconvenient to the user, unnecessary, deleterious, and contrary to design intention.

The user should be able to identify a document’s number, and to call up documents by number within Scrivener. And a Scrivener Loader should be available as an “Open With” option for the RTF extension, a pathway from a Scrivener document into its project.

Rgds — Jerome

Are you talking about external linking, for example from any program that can take a URL? If so we do have plans for a way of right-clicking on any object in the binder and getting URL for it that will basically tell Scrivener to load that project (if it is closed) and then focus the editor on the particular item. This way you could access individual Scrivener items from programs like Evernote, or even from other Scrivener projects as hyperlinks or References.

As for the technique you are using to create a link to the document from itself, I don’t follow what it is you are doing there, but continued improvements to making it easier to create links from within Scrivener should resolve the underlying reason for why you are compelled to store a hyperlink to each document from itself. That itself strikes me as being a clever way to get around other awkwardness. For example if you could just drag an item into another item’s text editor and get a link to it, would that should make things a lot less cumbersome.

I guess what I’m saying is, it shouldn’t be necessary or even more convenient to ever need an item’s internal identification number over using the interface itself. It should be our priority to resolve any problems that would make it easier to use the project by knowing the number. But if you do need it for your script, an easier method than the whole snapshot thing you’re doing would be to load a copy of the search index file in a text editor (one that can make navigating XML easier would be best; Notepad is a bit of a mess since it doesn’t read UNIX type files well). That has all of the ID numbers paired with the visible titles and full content. It’s pretty easy to read even if you aren’t familiar with XML.

Thanks, Amber. The URL approach will be extremely useful. But if we run a Windows search, the results are file lists. Right clicking on “2278.rtf” should enable the user to load that file in Scrivener, via a loader program that locates its project. If I search my folders for an economics term, I’ll obtain Scrivener and non-Scrivener file results. Those files that are documents should be loadable in the programs that created them, whether they’re DOCs, PDFs, or Scrivener’s RTFs.

So I’m hoping Scrivener will be as adept at loading a project from an RTF file path as it will be from name-based and/or number-based URLs.

Yes, I’ve worked with “search.indexes” a bit. As an XML, it’s most easily loaded in Chrome, with the ability to expand and collapse any level. But Scrivener maintains the index as live data, whereas a script is limited to the out-of-date copy on the drive. My index is also overlarge to plumb by script. It’s 2.8 mb, and its highest ID value is 7356, while my Docs folder is up to 7361. All new docs get a self-link. I throw a Snapshot because it produces the most reliable and up-to-date file numbers. I can generate the self-link even before there’s any text to search on.

All best – Jerome

wow you’ve gone a bit over my head from the original question.
But I’ve been away and basically written a spider that crawls the .scrivx file to give me a simple file number list, so now I can edit those files in an external text editor, so now my simple follow-on question, is:-
Does externally editing a text file cause any harm when Scrivener is re-opened? and if so, is it basic integrity that may be harmed, or just specific functions?