In my main database, I import almost all files and folders except for one that I share via seafile with colleagues. So, the data are in the finder and in the cloud, and Devonthink3 synchronises the changes in the finder.
Sometimes I move files from the databases (therefore imported files) into this indexed folder in the same database. I expect the files to show up in the finder, and they do, but with 0 content. In Devonthink, I get this sign except for the normal finder icon:
At the moment I can open these files in Devonthink, but they frequently cost me data loss since after a while, they seem to the accept the 0K finder content.
What do I do or expect wrong?
For the time being I think of a workaround in several steps:
Export files to the finder elsewhere (outside the indexed folder)
Move files to the indexed finder folder.
Wait for Devonthink to actualize the indexed folder in the data base.
It should be easier and I want to feel secure again with my data…
This icon just means that this document is linked by other documents. Was the content the expected one before moving the files? What’s the file size in the Finder, do you have read/write permissions? Anything in Windows > Log?
Icon: Yes, these documents are duplicates – the duplicates are in the indexed folder, and I think I moved them there even before indexing.
Both versions of the duplicates are fine in DTP3. But in the Finder, the earlier version is OK – as it always has been, but the version that I copied from another folder in DTP3 (not the indexed folder, it was an imported document) is 0 K in the Finder.
I am collecting data from the imported folders to the indexed folder, then I check whether everything has the right name and is at the right place, delete duplicates and want to have a clean indexed folder to share with my colleagues.
But now, the 0 K version and the OK Version appear, as duplicates, and I do not know whether I keep a 0 K file, when I delete one of them.
According to the screenshot this document wasn’t duplicated actually. How long do these duplicates exist, in which folder are they stored and is their path identical or not?
Yes, this particular version is not a duplicate, because I deleted the original for test purposes. The other one is in the trash can, it was the OK one.
First I checked the one left – which I showed in the screen shot. It has 0 K in the Finder and cannot be opened.
Then I moved the original one (36K) back into the indexed folder, and it is OK in the finder as well. – Both look good in DTP3.
Then I fully deleted the 36 K pdf in DTP3, emptying the trash can as well. Result: the one I copied into DTP3 is still OK; I can open it in an external application.
More and more I get the impression that the problem is the seafile cloud. I will test with an indexed folder on my desktop and come back in a few minutes.
I created a folder on my desktop and added files and duplicates in the Finder and inside DTP3. Both show up correctly in DTP3 and the finder. The icon does not show the link, but the normal finder icon.
The seafile folder in the Finder seems to link to another place in the Library. So this may explain the link icons in the problematic indexed folder; where DTP3 is doing everything OK.
We use the seafile cloud for academic work at our university, but I do not know how well it is known and whether it is worth setting up DTP to work with indexed folders on the Sea Drive. Of course, it is a shock for me to realise, that I cannot share work with colleagues from inside Devonthink, I would very much appreciate the system working…
I can’t tell from your many posts … did you EXPORT files from DevonThink into the local folder on your computer that Sea Drive software syncs for you? Did the files actually get OUT of DEVONthink?
Once there, if that folder indexed, I would expect DEVONthink to detect it. But an EXPORT probably is first step.
Hi, I hoped that my many posts were clear enough, sorry. To add to the quantity: I did not export from DTP, that was not the problem, but the move of an imported file in DTP to an indexed folder in the same DTP database.
And I think I wrote clearly that the files can be found in seafile (the Finder), and they only have 0 K and cannot be opened; DTP shows them as a linked file, as we learned in Christian’s first answer about the meaning of the icons.
No, with my testfolder on the desktop, Devonthink worked as expected.
As I have shown in the screenshot in the post from one hour ago, all files are shown as finder files in DTP3, and they appear as fully functioning files >0K in the Finder.
A Two duplicates, one in the desktop folder that is indexed, the other the one that I imported originally.
A1 File in the indexed folder; it is a file that duplicated in Devonthink and then moved to the indexed folder and shows up as a normal PDF with content in the Finder as well.
B2 This file was already in Seafile and appeared as a file in the Finder before I indexed the folder. Since I indexed the seafile folder months ago, it appears correctly in DTP, also it is fine on Seafile.
When I indexed the folder, DTP recognized it as a duplicate of other files already in my database (B1 above and B3 below, which was then still an imported file elsewhere in the database).
B3 The file that now shows 0 K in seafile and cannot be opened. It was originally in an internal DTP folder, and I moved it to the indexed folder yesterday.
I have other indexed files on dropbox and IONOS, no problem there. And I have now tested the seafile folder for finder search and synching with Chronosync, does not work. The finder integration is bad.
I created the folder “test-indexed-folders” within DTP, it is now a subfolder inside the indexed folder with its many subfolders.
I created the text document “original.txt” in an editor outside of DTP and saved it to the seafile folder in the Finder. This shows up and is OK in DTP.
Then I created another folder in the Finder and copied the text file to the folder, works fine.
Then I created another folder inside DTP and copied the original text file inside DTP to the new folder.
All files show up as duplicates in DTP, and they all have 77Byte in the Finder (SeaDrive).
Then I moved a PDF (2020 Article Ceramics) within DTP from its original internal folder to this one, and it shows up nicely in DTP, but has 0K and does not open in Seadrive/Finder. I returned the PDF to its original place, where it is OK, but the file still lives in the Seadrive.
Then I moved another PDF (meshlab…) within DTP exactly the same way and let it stay in the indexed folder. It is OK in DTP, but has 0 Bytes in the Finder.
I will now create screenshots from the info panels, then update the indexed folder manually inside DTP (it seems to work fine though without manual interference) and check the integrity of the database. You will get the infos in my next post.
I realized that the PDF moved from the internal group the indexed folder has not Finder icon, and it is stored in the database. That is logical in one way, but not what I wished and expected. The problem is that it shows up in the Seafile folder and somehow loses contact.
I updated the indexed folders in the data base, and this situation came up in DTP, while the Finder/Seafile still looks the same:
Apparently, DTP found the meshroom pdf and updated this in the database. But the meshroom file is of course empty, so it does not appear as a duplicate, and the finder still has only one meshroom pdf with 0 K. But the meshroom pdf without finder icon works. Here is a screenshot of the info panel.
That is what I could reproduce. I will try a copy to an indexed folder in the Finder in order to check whether there was an inconsistency with seafile or whether the problem is the one in front of this monitor…
It seems that Seafile/Seadrive is not reliable in this procedure.
Now I created a folder on my Desktop and indexed it in DTP. I copied some of my screenshots into the folder and they show up immediately, as they should. Then I copied a PDF from an internal folder as I did earlier with the seafile, but now the file shows the finder icon, the info panel shows the correct file path, it is recognized as a duplicate.
