Today I noticed that PDF files that I import using the sorter have a file creation date of 12/31/1903. It’s not an issue if I use the inbox in the finder. The modification date is OK.
I tried two different scanners, with and without running through OCR on a windows machine. The creation dates are correct before going into DTPO, wrong after.
That’s a weird one, and I don’t see such behavior here. Sounds like something got stuck in your computer’s memory.
Does the behavior persist after a restart?
It may not be as weird (I assume you mean uncommon) as you think. I’d guess most people rarely look at the creation date. I wouldn’t have noticed it except that I keep a date in the name of documents to represent the date of the document (as opposed to when it was scanned or modified). I have code that can get the creation date of the file and put it in the name, i.e. ‘2012-11-17’. I don’t use this method very often, usually I use code to pull a date from the text of the document and reformat it.
The short date format that DTPO uses doesn’t distinguish between 1903 and 2003, so you’re less likely to notice it (‘12/31/03 7:00 PM’).
I tried a restart, then tried a verify disk and fix permissions, the problem still exists.
Some additional info:
You can easily check open databases with Tools->Search, then click Advanced…, then enter (Date Created) (is less than) 1/1/1980
My oldest case was a scan on 2012-09-01, but there may have been other cases. I almost always change the creation/modification date to match the actual date of the document using Applescript.
I’m using 10.6.8.
I’ve gone through my open databases that include many tens of thousands of documents, including a number added via the Sorter – some long ago, some added via the Sorter very recently.
I only have two documents with a creation date less than 01/01/1999, both of which were created in 1998. I display dates as YYYYMMDD, so there’s no ambiguity.
That’s consistent with the way I started using DEVONthink back in 2000.
I don’t have an explanation for your issue of 1903 creation dates. But I wonder if that issue would continue if you test use of DEVONthink and the Sorter in a fresh Guest account, without any hacks that may be installed on your computer.
I did a Google search on ‘12/31/03 7:00 PM file creation date osx’ and found the following link to a discussion on the Apple forums concerning iTunes on Snow Leopard with files having a dummy purchase date of 12/31/03 7:00 PM. Just throwing this out in the event that there is a possible connection.
As a FYI, importing via the Sorter here on Mountain Lion gives me the actual creation date.
I assume 1/1/1930 7:00PM is a zero-value, invalid date.
I did a system-wide search in the Finder of documents created before 1940, they are all DevonThink Pro Office documents. There are 180 of them, most from a database I don’t keep open (in fact a test database from when I first started using DT). The search results are in:
~Library/Caches/Metadata/DEVONthink Pro2/[folder names of hex characters]
So, there are two groups of files, the recent files and files from the test database. When I get info on an individual recent files, the Finder something like this:
Note the Finder date for the cache file is valid, but the DT creation date is ‘–’.
The system-wide search in the Finder didn’t find the original files, only the metadata files. If I do a reveal of the actual file, here is what the Finder shows:
If I add a file using the fixed global “Inbox” in the sorter, then the creation date is OK. If I use any other item in the sorter, then the creation date bug applies. I now have three other items in the sorter, all are the Inbox of databases. I had two other folders within databases, which I’ve now deleted, that also exhibited the bug.
I tried putting a file in the sorter while DTPO wasn’t running, the bug still applies.
I tried deleting the two sorter preference files, the bug still exists:
The two sorter preference files don’t seem to include the inboxes/folders in the sorter (they came back after deleting the think-sorter preference files), can anyone tell me where they are stored?
I can’t reproduce your issue. I’ve just done several test captures via the Sorter, to the Global Inbox and to Inboxes of other databases. In all cases, the Creation Date was correct, both when viewed by Info in DEVONthink and when viewed by Info in the Finder.
I’m running DEVONthink Pro Office 2;4;3 under OSX 10.8.2.
When strange things happen, they can sometimes be cleared up by emptying the cache in the DEVONthink application and/or by a Restart.
If the anomalous behavior persists, try running DEVONthink in a Guest account. If the problem doesn’t exist in that environment, suspicion would turn to the software environment in your normal user account. If the issue is still present, try OS X maintenance (especially cache clearing) using a utility such as OnyX or C0cktail (but be sure to use a version of the utility that’s appropriate for your version of OS X).
I cannot reproduce it either-I just tried again because earlier I was testing with only the Global Inbox. Here is what I see on a document created from this thread, captured to a database inbox.
Clearing the cache didn’t help, but thanks for that suggestion. I’m not sure how running in a guest account would either help track down the bug or help me in particular, rather it would seem to be an attempt to prove that it’s not a DTPO problem. I did try copying everything to another machine, where the problem didn’t exist.
In any case, after many hours and multiple attempted fixes, I did solve the problem. I can’t say with certainty, but the evidence points to DTPO as the source of the problem. Here is the evidence, which also led to the solution:
When you import to DTPO using the sorter it does a file copy. The err doesn’t occur for the global inbox, but does for user-setup folders in the sorter. It occurs if DTPO is running or not.
Importing using any other method didn’t have the problem. Note that the Finder sidebar Inbox may move rather than copy, so one might expect different behavior. Other methods that do a file copy didn’t show the problem.
No other files on my system had erroneous dates (finder search), except for an old DTPO test database.
Restart, verify disk, repair permissions, empty DTPO cache all didn’t work.
Looking at individual files and with some deduction, it seems the error is in the Spotlight metadata set by DTPO, not the file system dates. DTPO keeps a second creation date.
My final successful analysis was that DTPO had likely messed up the Spotlight index, so recreating it was the solution.
I still wonder if others have this problem, as it could easily go unnoticed. Perhaps with the next person who finds it, you can track down the problem.
To other users who encounter this problem:
If you want to help track this bug, please contact Devon Tech to see if they want you to try some things. Since the problem only exists for a narrow case, there should be a fix. I can’t be that person now.
If you just want to fix it, rebuild your Spotlight index:
Restart, quit any open apps.
Open system preferences->Spotlight, then click the Privacy tab. Drag your startup disk icon to the Privacy list. This will wipe your Spotlight index. Note: if you have multiple drives, especially if your DTPO Databases are on another drive, do the same for the other drives.
Now click the line in the Privacy list for your startup disk, and click [-] to remove it from the Privacy list. The spotlight index will shortly begin a rebuild. The spotlight icon will show a flashing dot in the middle, and after a short time give you an estimated rebuild time if you click it. Don’t launch DTPO until indexing is finished.