Move book while editing

[BetterRed]

I was editing a book from within calibre GUI, after doing quite a lot of editing I realised it was a bigger job than first anticipated so I moved the book from my Main library to my UnderEdit library.

But silly me hadn't saved the book I was editing, so when I went back to the editor to close it, I got the "Do you want to save your work" popup, clicked Yes and got OSError: [Errno 2] No such file or directory. So I had to save a copy, and replace the epub in my UnderEdit library with it.

If I make the same blunder when I have a DOCX open in Word or a PDF open in Xchange, then when I try to do the move I get the error message IOError: [Errno 13] File is open in another process: . So I have to go back to Word or Xchange to save and close the file - before re-doing the move.

So my question is - if the calibre GUI can detect I have a DOCX or PDF open in a 3rd party Editor when I try to move a book, then should it not detect I have an EPUB open in its 'own' Editor when I try to move a book?

BR

[jackie_w]

It's not quite the same though, is it? As far as I understand, when you open an epub in the editor it is exploded into a directory (or directories for multiple Checkpoints) within your calibre TEMP directory and all your edits are on exploded temp files not the original epub. So the OS wouldn't know the original epub and the temp files are related. I make no comment on whether calibre knows they're related, because I don't know.

I think the original epub itself only re-enters the scene when you Save.

I'm sure someone will put me right if this is wrong.

[BetterRed]

Originally Posted by jackie_w

It's not quite the same though, is it? As far as I understand, when you open an epub in the editor it is exploded into a directory (or directories for multiple Checkpoints) within your calibre TEMP directory and all your edits are on exploded temp files not the original epub. So the OS wouldn't know the original epub and the temp files are related. I make no comment on whether calibre knows they're related, because I don't know.

I think the original epub itself only re-enters the scene when you Save.

I'm sure someone will put me right if this is wrong.

I would have thought it needed to open the EPUB to explode it into Temp

Just as an EPUB is a rebadged ZIP so also is a DOCX. So I would imagine Word has to do something similar to Explode to create its workfile.

You can see Words workfile, if you unhide hidden files - it will have ~$ in front of the name - but its the input file, ie the DOCX that's in the library, that gets locked. And Word wont write to that DOCX until you do a save, just like ebook_editor won't with an EPUB. If Word can lock its input file when it opens it then...

Not all 3rd party programs lock their input file, eg WinRAR doesn't. So if you move a book that has a ZIP that's open in WinRAR to which you've added some files but not done a save then calibre will do the move and when you do the save in WinRAR then it will throw a No such file or directory error, there is nothing calibre can do about that.

BR

[kovidgoyal]

calibre does not lock the file it is working on. I see no reason to do so, it reduces interoperability between programs and is a windows only feature (windows is the only platform that has mandatory file locks). In fact, the saving code in calibre is designed to be atomic without locking. So when you save, the original file is not written to, instead a new file is created and then renamed to the original. Since ebook formats dont support in place updating in any case, this approach makes the most sense.

If you do happen to move/delete the file externally, as you discovered you can always save a copy. And note that the failure only happens if you move/delete the *folder* in which the file is, not the file itself.

I could probably make that option prominent on the error dialog when a save error occurs.

[kovidgoyal]

https://github.com/kovidgoyal/calibr...4d212e517e4415

[BetterRed]

I don't think locks are mandatory in Windows, my observation is that they're optional.

WinRAR does not lock an open ZIP, Irfanview does not lock an open JPG, nor do notepad++ or notepad lock an open TXT file. With each of those programs I can change the folder path to a file they have open, but then I have deal with the error when I try to save it. There's nothing any program can do about that... except WinRAR, Irfanview etc.

I would always prefer to have the folderpath change refuse the request, rather than allow me to blithely proceed, thus forcing me to deal with the consequences later. The effort to save and close the file in order to allow the folderpath change to proceed, will almost always be less than saving a copy and getting it to where it ought to be. And the latter is an exception to normal practice, all of which makes it prone to yet more user mistakes.

BR

[kovidgoyal]

I meant that the ability to lock files with mandatory locks is windows only. No other platform even has the ability.

And read the commit message on the link I posted earlier. Now if the file is removed/deleted while the editor is open, when you try to save the editor will ask you for a new file name. This solution works on all platforms, not just windows.

[BetterRed]

I wouldn't be at all surprised if Windows didn't inherit file locking from OS/2.

Yep, saw the change

BR