PDF naming

Hmm this is a little scary at first glance. I kind of just wish it could change 1 file at a time instead of going throught the whole database. I’ll cross my fingers and give it a whirl!

My usual “belt and suspenders” advice: Whenever you are not sure what may happen, do it to a copy of your database. :slight_smile:

This operation also affects the external files in the Finder. Got a backup of your disk? (Although I don’t think the script will damage the files.)

Let us know if you have any problems.

I have the same problem of dealing with pdfs. I download something like CS-TR-05-14.pdf (Technical Reprt #14 in 2005 from the Computer Science Department somewhere) and import it into DevonThink with the copy going into it’s Files folder for security. Then I rename it something sensible like Jones 2005 Super Fast Whatevers.pdf. Eventually I would like to have the new name show up as the MacOsX name for this file.

I would hope that the new name might get applied when I do an export.

An issue is that Jones may produce a new version which is nicely formatted with a bit of new material for some conference (called something new for the conference and session) and I will pick it up and give it the same name in DT. DT is quite happy to have two different files with the same name because it has not done a real rename, only a virtual one. This would cause trouble for an export with new names. I would be quite happy to have the second file named “whatever (dup name)” in the style of Apple’s use of “copy” when I duplicate a file. If I have done other sins in picking a name I would expect export to grumble.

At this point I still just starting with DT so must admit to not knowing my way around it. I am not quite sure what the advice is in this thread. What happens with the duplicate names? Repeating it in “words of one syllable” would be greatly appeciated. (Where is the spelling checker on this thing? My news reader has one.)

I follow a similar practice. I download PDFs and import them into DT Pro. In DT Pro, I usually give the document a name that makes sense (usually the title of the article or book).

To this point, I don’t worry about changing the name of the PDF in the Finder, as DT Pro will let me find and open the PDF instantly.

There will be changes in Version 2 that will make some of your questions moot, especially if you directly import the PDF files into the database rather than indexing them. But that’s another story for the future. :slight_smile:

I do not understand two points.

  1. The manual seems to recommend against taking the pdf file into the database but rather just into DT’s managed folder. Makes backups possible as the changes are to things a backup program like Retrospect can deal with. Telling Retrospect to ignore what is in fact the whole collection of pdf files is not acceptable.

  2. There are a variety of reasons for wanting the pdf to eventally have a legible name. Like being able to send it along to someone else. How do you attach something inside the DT database? You export that piece on demand instead of doing a batch export to keep things fairly rational.

Or do I wait for version 2 of the fancier product?

By “imported directly into your database” I meant content imported either into the database or into the Files folder inside the database package. Indexed files remain external to the database package, for example.

The Version 2 database structure will have a major revision.

All the database contents will be stored in the Finder, inside the database package, and in folders and sub-folders approximating the organizational structure of the groups in your database. Therefore, Spotlight will be able to index all the files.

Also, the files stored inside the database package will have filenames approximating the names you have given them in the DEVONthink/DEVONthink Pro database. (I say approximating, because some characters such as colons, which are common in the names of books and articles, will be changed to avoid creating illegal file names.)

Memory requirements will be lower and search speeds faster in the new database structure.

Until then, it’s always easy to rename a copy of your PDF file to send to a friend. Or, you could use the renaming script for Files & Folders under DT Pro’s Scripts > Path & URL mentioned earlier in the thread. (I haven’t used that script myself, because I’ve got other applications using folder action scripts and aliases for some of the folders in which my Indexed PDF files reside, and don’t want to take a chance on breaking those links and scripts.)

I don’t look on the lack of synchronization between internal DT filenames and external finder filenames as a bug or a bad design choice- I think it’s a very insightful and deeply correct design decision! Finder filenames are old fashioned thinking. In DT, on the other hand, I can happily name two files the same thing. Why not be able to do that? They are disambiguated by the creation date, content, etc. etc. User-visible filename need not be unique, since the true filename, (think unique database key) should anyways, (like all unique keys), be hidden from the user. Inside DT, I can treat filenames the way that they were meant to be treated, as arbitrary descriptive naming text with full flexibliity and power and no disallowed special characters, unlike in a more primitive naming scheme like the finder. Imagine a database where the user went around willy-nilly changing the unique database keys as arbitrary text. Or a database that let the user have two things with identical content but different titles, but not two things with identical titles but different content. That’s pretty much how finder presents itself.

With DT I also get all file appearances within a database as equivalent aliases to a hidden source, just like it should be.

p.s. I import files into dt and kill the original finder-based copies, to be consistent. And I don’t use it as a wholesale finder replacement, just for certain well-defined tasks (research literature).

What was being asked for was the ability to EXPORT WITH THE NEW NAME. All the technical reasons stated for not renaming inplace are true and refelect sensible design. But exporting with the silly name reflecting the session and paper number of a pdf downloaded from a conference is not very good human engineering. I would fully expect that the export names would have to be plausibe names for the external filing system, so there has to be an accommadation for special characters and duplicates. The representation of the request as a claim that there is a design error is an overstated straw man.

One reason for wanting plausible bulk exports is a certain disbelieve in the everlasting nature of every last piece of software. The number of utilities around to convert mailbox formats should show that the issue is quite real. Sometimes one even has to change the underlying system to achieve other benefits even if a downside might be losing the use of DT. Is there a DT for Windows or Unix/Linux/*BSD or etc? Black holes, which only have things going in and nothing coming out (neglecting Hocking radiation), may be interesting physics but they are rather poor pieces of software. Describing something as “write only” usually a serius nonprofane way of damning it. If the export ability is so limited it is effectively broken then the same judgement quickly gets applied to the rest of the system. Since the DT internals are exactly that if one wants to move the information to some other application then a clean export which does not discard the information accumulated in DT is of the essence and would be a sensible mature capabilty of DT.