2.0b7.4 - not deleted (PDF) attachments (filesystem)

zroutik
Dear devs,

using Zotero 2.0b7.4. In the Library
- an item has an attachment
- item deleted (Remove from Library.., with attachments & notes checked)
- chacked in Trash, Trash emptied
- BUT: In the related attachment directory "storage/EXAMPLE012/" Zotero deletes only the .zotero-ft-info and .zotero-ft-cache files. The PDF remains untouched -- there is no traces of the PDF name after all in the Library, though.

Need more information?

Cheers, Z
  • zroutik
    Deleted tens of items with attachment this way. One was deleted OK also from the FS (WinXP).
  • zroutik
    edited December 10, 2009
    If anybody want to check their indexed Library -- this was my way to delete files already "deleted" and not included in the Library:

    command-line in Storage directory:
    - storage> dir /s * > dir.txt

    edit with vim the dir.txt file and search for unindexed pdf (the index files are regularily deleted, see above)
    /\.\.\_$\_.\{-40}\(\.zot\|(\|.*\.\(djvu\|od\(t\|p\|s\)\|doc\|txt\|gif\|png\|7z\|rar\|css\|html\|zip\)\)\@!
    or
    /\.\.\_$\_.\{-40}\((\)\@!\(.*\.pdf\)$
    the pattern searches for directory without an index file on the next line. in the following example:

    [code]
    Directory of W:\papers\storage\MKJJMII3

    10/21/2009 11:13 AM DIR .
    10/21/2009 11:13 AM DIR ..
    03/29/2005 08:09 AM 66,843 Thamizhmani05.pdf
    1 File(s) 66,843 bytes

    Directory of W:\papers\storage\MKTE6D5X
    [/code]

    Cheers, M

    p.s. I've just found out that .doc, .djvu, .odt, .txt and .pdf with special character (ě, ü, ř, —(emdash)) in title are not indexed :(

    edit 2009-12-10: changed search pattern
  • dstillman
    I can't reproduce this.

    1) Are you positive the trash is empty? The files are only deleted when the trash is emptied, not at "deletion" time.

    2) Are the files open in another program at the time?
    I've just found out that .doc, .djvu, .odt, .txt and .pdf with special character (ě, ü, ř, —(emdash)) in title are not indexed :(
    This is a Firefox bug.
  • zroutik
    edited October 22, 2009
    Thanks for checking Dan!

    reg 1) positive. Trash emptied. I even closed Zotero, to finish the Firefox session -- to be sure the process is not hanging in bg.

    reg 2) nope, they are not (unless they are indexed in the meantime, which I can't check -- but I imported them a while ago, so I doubt). Some of them where even not open by any other program than zotero indexer.

    I think I have found out more: when I remove an item with an attachment from the Library, the related attachment appears grey in the Trash, even "remove attached notes and files" was checked (positive, unchecked & checked). (I missed the grey colour yesterday, not reported.) So, Zotero does not send the attachment to the Trash with the item, then it is understandable that it does not remove it from the folder/HDD. Furthermore, there are no traces of the file name (former attachment) in the Library, anymore.

    Zotero does not send the attached file to the Trash with the item -- independently whether the attachment was highlighted with the item or not. If the attachment was highlighted itself it is sent to the Trash and the parent item is grey while the attachment is normal black (correct, supposed to be deleted and is deleted from HDD, checked).
  • dstillman
    Are you deleting items from the trash using Empty Trash or by selecting items and deleting them?

    If the latter, is "Remove attached notes and files" checked or unchecked?

    It's possible this could occur if you manually removed items from the trash with that option unchecked. I can't really think of any other way it might occur.

    In the latest dev build the option to not remove child items (which apparently wasn't showing up on OS X anyway) has been removed, since it doesn't really make sense in the context of a trash-based deletion process and was causing various problems. I'm hoping that this bug, whatever it was, was fixed along with that.
  • zroutik
    Thanks Dan.

    I was always using Empty Trash function to delet the Trash.

    Positive, "Remove attached notes and files" has been always checked (-- but even it was checked, the attachemnts were grey, as mentioned above).

    I believe, you mean the beta thread by "dev build", so I just wait for the next 2.0b and I'll post my observation here.

    Regs, M
  • zroutik
    edited November 26, 2009
    Dear devs,

    I'm back with the report on the issue, using the fresh 2.0b7.5 version. Thanks for the update :)

    The files are now deleted from the FS without traces. But there is one other unclear additional behaviour:
    - when a parent (or a parent-child highlighted pair) is deleted, in Trash, the parent appear bold (status "has been deleted"), but the children appear grey (status "is child, not deleted"). This is erroneous: both should be bold. When Trash emptied, both are deleted from FS.
    - when a child is highlighted/selected and deleted, in Trash, the parent is grey and the child is bold -- statuses are correct and when emptied, the child is correctly deleted from FS.
    - so, to keep the child in the Library, first one has first to move the child away from the parent item, and then delete the item itself. Otherwise, the child is always deleted independently of the grey/bold status indicated in the Trash.

    Cheers, M
  • zroutik
    edited November 26, 2009
    2&2 libraries on 2 computers behave the same, as descibed above. one has been upgraded from 2.0b7.1, the others from 2.0b7.4. May I supply other information, or a library itself? Cheers, M
  • dstillman
    when a parent (or a parent-child highlighted pair) is deleted, in Trash, the parent appear bold (status "has been deleted"), but the children appear grey
    Fixed in the latest dev build, and the fix will be included in 2.0b7.6. Thanks.
  • zroutik
    edited November 30, 2009
    I'm really sorry, I'm back with the very old issue. It's the issue the tread had been started with.

    Zotero deletes the items (both parent and child (PDF)) into the Trash as requested. But only .zotero-ft-info and .zotero-ft-cache files are deleted from the File-System when "Empty Trash" is selected. This happens also when the child is deleted only (i.e. the .pdf file remains untouched)

    I'm positive this didn't happen in b7.5 (I reported the "grey" mis-colouring), but I was not able to check again: I tried to download the b7.5 version, but unfortunately, the conjectured link http://www.zotero.org/download/zotero-2.0b7.5.xpi does not work for me (although, recreating the link for 7.4.xpi does--that version is not relevant now).

    Cheers, Z

    p.s. I checked with the "Unlocker" tool (freeware) that the .pdf files are not locked by any other application.
  • dstillman
    I checked with the "Unlocker" tool (freeware) that the .pdf files are not locked by any other application.
    Meaning "any application" or "any application other than Firefox"? If Firefox has the file locked—say, if you have the PDF open—it might not be deleted (though I would expect you to get an error message).

    I don't believe anything changed in 2.0b7.6 that would have restored this bug.

    If you're sure you're still seeing this, provide a Report ID and a Debug ID.
  • zroutik
    edited December 9, 2009
    1) I turned on the JavaScript Error window, but have found not error related to Zotero.

    2) I believe I got the rest (debug log) right, here it follows:
    Ten files was deleted using Trash, but only two of them were actually deleted from the FS.

    Debug sent:
    "Debug output has been sent to the Zotero server.
    The Debug ID is D1910863196."

    3) I had exported the files I was going to delete beforehand and here is the list after comparison what has left after "Empty Trash":
    http://img138.imageshack.us/my.php?image=deletedbutnotdeleted.png

    Tell me, pls, if you need any other information.

    Cheers, Z
  • zroutik
    Dear Dan,

    I have found out the reason why the files remained untouched and non-deleted. The files (PDFs) were set to be read-only. After globally unsetting the read-only attribute to all files in the Storage folder, no 'left-overs' are present :)

    I remember they were copied from a colleague at the time, I can't check on their former attributes anymore, but I have found this topic related to import:
    http://forums.zotero.org/discussion/9111/prevent-copied-pdf-files-being-readonly/ , IMO.

    Dan, thanks for your time. And thanks for keeping up the perfect work. I'm looking forward to 3beta testing.... ;-)

    Zroutik
This discussion has been closed.