Linux error in new trash management

Bug #2023476 reported by John Veysey
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
calibre
Fix Released
Undecided
Unassigned

Bug Description

When I try to delete things, for instance a specific format of a book, I get a "same file error". It appears to be a parameter passing issue?

calibre, version 6.20.0
ERROR: Unhandled exception: <b>SameFileError</b>:'/home/veysey/calibre/J. K. Rowling/Harry Potter and the Order of the Phoenix (106)/Harry Potter and the Order of the Phoenix - J. K. Rowling.mobi' and '/home/veysey/calibre/.caltrash/f/106/mobi' are the same file

calibre 6.20 embedded-python: True
Linux-5.19.0-43-generic-x86_64-with-glibc2.35 Linux ('64bit', 'ELF')
('Linux', '5.19.0-43-generic', '#44~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon May 22 13:39:36 UTC 2')
Python 3.10.1
Interface language: None
Successfully initialized third party plugins: DeDRM (10, 0, 3) && Kindle Collections (1, 7, 29) && Kindle hi-res covers (0, 5, 0)
Traceback (most recent call last):
  File "calibre/gui2/actions/delete.py", line 222, in delete_selected_formats
  File "calibre/db/cache.py", line 85, in call_func_with_lock
  File "calibre/db/cache.py", line 1898, in remove_formats
  File "calibre/db/backend.py", line 1552, in remove_formats
  File "calibre/db/backend.py", line 2053, in move_book_files_to_trash
  File "calibre/utils/copy_files.py", line 169, in copy_files
  File "calibre/utils/copy_files.py", line 52, in copy_all
  File "shutil.py", line 434, in copy2
  File "shutil.py", line 234, in copyfile
shutil.SameFileError: '/home/veysey/calibre/J. K. Rowling/Harry Potter and the Order of the Phoenix (106)/Harry Potter and the Order of the Phoenix - J. K. Rowling.mobi' and '/home/veysey/calibre/.caltrash/f/106/mobi' are the same file

Revision history for this message
Kovid Goyal (kovid) wrote :

That indicates you somehow have hard links to the book file in your trash folder already.
You can simply empty the trash to fix the issue, but I would be
interested to know how the issue happened in the first place.

Did calibre crash during a previous delete attempt? Or is there
something unusual about the filesystem you have your calibre library on?
Can you come up with steps to reproduce the problem, after emptying the
trash folder?

Revision history for this message
Kovid Goyal (kovid) wrote :

And in this case I can just ignore this error since its harmless, which will fix this bug but I would still like ot know how it happens.

Revision history for this message
Kovid Goyal (kovid) wrote :

Fixed in branch master. The fix will be in the next release. calibre is usually released every alternate Friday.

Changed in calibre:
status: New → Fix Released
Revision history for this message
John Veysey (veysey-junk) wrote :

Thanks for the quick reply (and fix!). I don't think there was any crash. The file system is vanilla — ext4.

I reproduced the problem by emptying the trash (and confirming that the mobi file was gone in .caltrash). Then clicking on a book with both e-pub and mobi formats and attempting to delete just the mobi file ...
1. Reproduced the error
2. Showed that mobi file in the trash. It also shows up in the trash when I go to empty it. But: The mobi file also remains in my library (as it probably should with an error)

However: It only appears with some books, like Harry Potter, where it is consistent. I am able to delete others as expected. Curious. I'll try to figure out a pattern in books that fail. And look forward to trying the next release.

Cheers

Revision history for this message
Kovid Goyal (kovid) wrote :

Doesn't repro for me on ext4 Linux, so if you can figure out what's
special about the files, that would be great. Maybe tar up your library
folder and attach it here and I can try to repro with that. Mark the bug
private if you do that (or just create a copy of the folder with only
metadata.db and one book that shows the issue).

Revision history for this message
Kovid Goyal (kovid) wrote :

Actually, I think I know why it happens. File movement happens in two steps hard link followed by copying of file metadata. If the latter fails then that will cause this error. My fix will make it ignore the failure to copy metadata. I am guessing some owner/group/permissions or something like that are not copyable for the files in your library for the user account you are running calibre as.

Revision history for this message
John Veysey (veysey-junk) wrote :

Hi Kovid — Your last guess was on to it. The problem was that the file owner was root, not the user. User had some permissions but not others. Fixing the permissions let the files be deleted by calibre as expected. Probably still best to ignore the error, though it is likely too obscure to matter!

I think it was an artifact of a restored backup. Cheers and thanks again!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.