Show in Finder shows file name changed

I just used the “Show in Finder” button on the toolbar to see an imported file in the Finder, as it appears in DEVONthink’s Finder structure, and puzzlingly the name has changed to have “-1” appended to the end (disregarding the extension).

Why might this have happened? What might this betoken?

E.g. if there was already a file with the same name in the enclosing folder.

Hm… OK. Not sure how that could have happened. If it had been a sync conflict, wouldn’t it have had “-copy” appended? Can it be renamed back somehow, or should I leave the filename alone?

I’d leave the filename alone at this point.
You say it was imported not indexed?

Well if that’s your advice, I’ll leave it alone I guess, though I don’t really want it to be renamed.

Yes, it was imported, not indexed.

Is this a database with a large number of files of the type you say got renamed?

The database comprises 3,100 files, but only 19 of the type that’s affected (.scriv Scrivener package files). I see that out of those 19, two have had this “-1” renaming, both being in the same group.

I suppose I could export those two files to a temporary safe place, rename them, delete the two in the database and empty the DT trash, sync, and then re-import the renamed files back?

But I wonder why DEVONthink took it on itself to rename them.

The internal filenames might vary, File > Export > Files & Folders… should use the desired names.

It’s unclear from your description if only the disk file name has been changed, or if the name as it is presented in DEVONthink has also been changed.

I recall having having seen file names on disk be different when I imported files with the same name into the same group in the same database. The name in DEVONthink stays the same (because the way names of any kind are handled in a database is different and they don’t have to match one-to-one to names given to files on disk) but the software has to rename the file on disk to avoid a name collision.

Only the filenames in the Finder changed. I understand the mechanism you’re referring to, and I see how it’s useful if one must import files of the same name.

But the names of the files in question, both in the Finder and in DEVONthink, were unique in the database. So I was surprised when I saw them gain a new Finder name without any apparent reason.

Is it possible you had previously imported something with the same name, and had deleted/trashed it in DEVONthink, without emptying the DT trash? If so, the seemingly-unique name may not actually have been unique – it might have existed in DT’s trash. (Although, to be honest, I’m not 100% sure DT would keep trashed items in the same internal folder structure as other items, so I can’t be sure a name collision could occur in this situation. Just seems plausible. Maybe the devs can say.)

I see that possibility, but I’m almost certain that I didn’t do that. The files had unique and distinct names which weren’t repeated anywhere in the database, and they’ve not been trashed since they were imported.

I know I shouldn’t worry too much about the names that DEVONthink gives them in the Finder, for the reasons you describe, but this apparently spontaneous renaming was odd. A glitch, I guess.

Files are only renamed if there’s a already a file with the same name in the destination directory.

Same name - and same file extension? In the case I’m reporting there have never been any other instances of files with the same name and extension anywhere in the database, so I don’t see how a name collision could have occurred — assuming collisions can indeed only occur between files which are of the same name and the same extension, and which both also somehow find themselves in the same “extension named” folder and lettered/numbered sub-folder that DEVONthink creates for them in the Finder (the “destination directory” you refer to).

Exactly. And the location in the database doesn’t matter, only inside the filesystem (in case of imported files this means inside the .dtBase2 package).

Well like I said, there have never been any other instances of files with the same name and extension anywhere in the database.

I was concerned about this because the “-1” suffix made me suspect a copy or similar - but hopefully it is just a case of the name and not the package file itself.