Running 2.0.7. I tried repairing permissions with Disk Utility, reinstalling the add-ons, rebuilding the database, Verify & Repair, and Backup & Optimize.
When I try to import a file using File>Import or using the Drag and Drop method, the file is not imported. The log only shows “Failed” in the info status. I can’t import into either the Global or my personal database.
Any suggestions for my next step, barring reinstalling the application? I’m really not interested in reconfiguring my folders, scan settings, etc. if I don’t have to.
In Preferences > Import - Files, make sure that all the options (including ‘Other’ are checked. Otherwise, certain filetypes may be excluded from import.
DT may see the file as damaged or malformed and refuse to import it. Sometimes resaving the file in an external application might clear the issue so that DT will accept it. Suggestion: Attach your ‘strange’ file to a message to Support, with a description of the issue.
All options are checked under the Import section. Encoding is set to automatic.
The PDF files were malformed. They were 0 byte length but Finder was showing them with the original size (Terminal shows the true size).
I’m pretty sure they became malformed during one of the imports (I was testing the Finder integration with the Global inbox) because it replicates a previous (unreported) issue I’ve noticed. Sometimes I’ll come across a PDF file in DT using the browser which shows “No Selection” in the preview window. The size in DT shows an actual file size. The file will not open with Preview or Adobe.
Visiting the file in Finder shows it has a size, but again Terminal shows that it’s an actual empty file.
When I say “sometimes”, I’ve probably run across 100+ of these in my 4,000 document database. I noticed it started after I created a second database and tried drag-n-dropping files from my main database into the second database, then back to the main again (decided against a 2 database organizational structure for now). Many, if not all, of the files I swapped between databases had become corrupt in the transfer and are now 0 byte files. There are some other files which were not swapped between databases but are also 0 byte files.
I’ve tried searching through the file system (Spotlight) and there are no backups of these files. So far, the files which have been lost have not been critical irreplaceable files so it hasn’t been much of an issue, but I’m concerned about the reliability of the software.
I could send you one of the files, but it’s really just a 0 byte file so there’s not much there to look at. I’m a bit hesitant about the reliability of DT Pro because I don’t know what causes these files to essentially delete themselves. The import shouldn’t, under any circumstances, make the file a 0 length file. I do all of my OCR using ScanSnap, and I’m certain the files had a length (normal files) immediately after scanning (I review the file and auto classify almost immediately after scanning, before I shred the document). I don’t touch inside the DT database for any reason (it’s not backed up via Dropbox or anything which would corrupt the database)
I’m inclined to think that it occurs when I’m doing my verify or my optimization, but there is really no rhyme or reason to which files are corrupted.
DEVONthink doesn’t do anything to alter the file that’s imported. It is simply copied (if Imported) to the ‘Files.noindex’ folder within the database, and is actually stored in the Finder there, in its native filetype.
Any damage to files during the copy procedure would result from other causes including disk directory errors, or an incomplete or damaged copy resulting from an aborted copy (Force Quit, application or System crash, a power outage or severe voltage fluctuation, etc.).
Finder’s an application, Bill. Tough for files to be “stored in the Finder”, unless you mean those within its application bundle. It’s more accurate to say DTv2 documents are stored as regular files in the filesystem.
True, and I often say that the files stored in ‘Files.noindex’ are stored in Apple’s filesystem.
But all too often, I get a Support message reply asking, “Do you mean stored in the Finder?” So I reply, “Yes.”
Sometimes there’s precision of terminology, and sometimes there’s communication. The point to get across is that files stored in ‘Files.noindex’ are accessible via the Finder. Maybe that’s what I should say.
I understand the file structure and that DT stores the files in the file system, rather than in an actual database (it’s one of the reasons I chose DT over the other options at the time).
I’ve amassed 4,000 PDF files over the years and previously kept them in a number of other systems (file system, Leap, Evernote, etc.), but I’ve yet to lose one randomly on a disk or in another system, or even entire groups of files.
I can target the one group of lost files specifically to a set I moved between 2 DT databases. The others, I’m unsure of, but they appear to have duplicate file names and may have been files which shared the same name but may have been different files (ex: 1 file is OCR’d but the other wasn’t, sometimes I have two copies of the same file). But not in all cases, some files were single unique files. In almost all cases, I’m willing to bet the file was already OCR’d. I OCR all my files using Scansnap when possible and I turn the auto-OCR feature in DT off (I haven’t found the sweetspot for speed/size/quality in FineReader)
Possibly it’s a user error–I tend to import, review, auto-classify then delete the file following the import. Perhaps I’m too fast in my delete (DT imports pretty fast though) and there is a hidden dialog box I miss in the background (but I don’t think so).
Whatever it was, I was able to replicate it just this evening by the following:
I have 3 DT databases, a MAIN (4k documents) and a TEST database, and the GLOBAL. I’m working in the INBOX of each database.
I created 20 PDF files by creating a document in Pages (just said “Test” in it) titled Test.pdf and using CTRL+C/CTRL+V. I also added a single PDF file I downloaded from the Internet (a vector PDF file of a map of Nebraska).
I drag/drop the 21 files into the TEST database main window. All goes as expected.
I drag/drop the files back into the GLOBAL and the MAIN databases, pausing between each drag/drop and testing the files at each step. I moved the files less than half a dozen times between the 3 databases (testing all combinations). Everything looked good until…
EDIT: I did to a Verify & Repair and Backup & Optimize on the TEST database at least once when the files were in the database. I’ll see if I can leave this step out when I replicate to narrow the issue down.
My final final drag/drop back to GLOBAL, the documents are ALL empty 0 length files which show NO SELECTION in the preview and are not able to be opened. The content is gone, they’re essentially wiped clean.
When I “Show in Finder” the documents exist. Finder shows the “should be” size. The files are empty as shown in Terminal. HoudahSpot shows the files exist 1 time each (there are no duplicates).
At no point did I jump into the DT database or modify any files or check the content. The Sorter is turned on. The Destination of the Import is set as the Inbox of current database, if it matters. It’s bedtime here but I’ll follow up with a post tomorrow and test it again to make sure I can continue to replicate this behavior.
As above, this mimics my workflow at times–I dump things into the global inbox as a sort of a stack to group and organize documents which have already been imported (say, to tag or put in a Group together). At the point they’re in global I’m never reviewing the file, however, because I’ve already ensured it was complete at import.
Comments and testing by others to replicate are appreciated.
No luck replicating it again using the same set of PDF files (I tried twice). I do see that I have an issue with the Inbox link in the Finder for sure–no files can be imported by drag/drop to the Global Inbox in the Finder.
Might be an issue with my install so I may try a fresh install once I get my data backed up.
Tough for files to be “stored in the Finder”, unless you mean those within its application bundle. It’s more accurate to say DTv2 documents are stored as regular files in the 
