Menu
▾
▴
#1019 Skim blocks emptying trash
I am using the latest version of skim on OSX 10.10.2
- Open file.pdf
- Close file.pdf
- Trash file.pdf
- Cannot empty the trash because "file.pdf is in use"
- Quit the skim app
- Can now empty the trash
I should be able to empty trash with file.pdf since it is closed even though skim is running. All other app's work that way (eg., excel, word, ...)
I have no idea what would does this, because we don't hold a lock on the file.
If you need any further information let me know. This behaviour has been there for at least a few versions.
Annoying but not a show stopper.
I see this as well. Locks have nothing to do with it; it appears that Skim does not (sometimes, at least) close files when the user closes the window. You can check this using lsof (just give it the filename as an argument, and remember to run it with sudo).
A workaround is to just run the following command in a terminal window:
Well, that would mean that it is about locks. What lsof shows is locks on files (they just call it "open file" in the man page, but it really means "having a lock on a file").
And again, we don't put a lock on the file (except one that most definitely is not the problem). Only the system does. And we cannot look inside the system. (And this also did not happen in 10.9 and earlier, also showing this really is an OS bug.)
I find that quite surprising.
To me, an open file means the process has an open file descriptor on the file. And a lock on the file is the result of having called flock() or lockf() on an open file descriptor.
In fact, if I create a file /tmp/foo and run
then lsof will report that the sleep process has an open file descriptor on /tmp/foo. I am quite positive that the shell does not acquire a lock on a file used for redirection, it just calls open() on it and passes the resulting file descriptor to the subprocess.
Okay, so let me try to be a bit more constructive. I agree that I didn't see this in 10.9 and earlier. I suppose you are using some system supplied higher level library to access and parse the PDF file? In which case, a reasonable hypothesis is that this library used to close the file descriptor automatically, whereas it doesn't do so in 10.10. Perhaps it now requires the application to do some extra work to ensure the file descriptor is closed, or maybe it really is a bug wherein a finalizer is not run, or something along those lines.
An open file descriptor is a kind of lock. It's what I mean by it in my comments. I am primarily talking about open file descriptors. And again, we don't use them.
And yes, of course we use system libraries, that's what makes a Cocoa app. And that they don't automatically close the file descriptor is essentially what I am saying. But it must be done automatically, as we cannot even do any extra work, as we cannot know what happens behind the scenes. (And Apple also does not tell us we need to do extra work, in fact, for compatibility reasons that would not even be acceptable behavior). So it must be a bug where the system does not close the file descriptor, but it's their responsibility.
Well, then it seems we are converging on a mutual understanding. Thanks for explaining it. I am not used to programming at this level, usually having worked closer to the iron. (I think I disagree that an open file descriptor is a kind of lock, but this is not the place to quibble about semantics. I do understand what you are saying, now, and that is the important part.)
I suppose (and hope) you have filed a bug report with Apple. You'd think this bug would affect a huge number of apps … But I know, of course, that Apple does not usually provide great feedback on bug reports.
Unfortunately the information I have is far too vague to file a report with Apple, it would certainly be closed immediately because of insufficient information.
BTW, it does look like it's PDFKit's PDFDocument (though probably something more primitive inside it) that has an open file descriptor, so that's probably the place of the bug. That also explains why this does not happen with most other apps.
Okay. And when the user closes a window, is it PDFDocument that responds to this event and takes care of everything? If that's the case, and your code is not involved in this at all, that certainly explains why there is little or nothing you can do about it. But it also seems specific enough that it ought to be possible to file a bug report with Apple.
It's not responding to any UI event, it knows nothing about the UI. But it is responsible for cleaning up its internals (including any file descriptor it may keep) when it is fully released. That's how Cocoa works. And we fully release it.
Apple's demo application has the same problem.
https://developer.apple.com/library/mac/samplecode/PDFAnnotationEditor/Introduction/Intro.html
This bug, or a new one just like it, seems to be back. Right now, I get this:
; lsof -p1630 | grep -c '.pdf$'
58
(1630 is the pid of the current Skim process).
And yet, I have closed every single Skim window.
And there are about a dozen pdf files stuck in Trash.
– Harald
-----Original Message-----
From: Christiaan Hofman hofman@users.sf.net
Reply: [skim-app:bugs] 1019@bugs.skim-app.p.re.sf.net
Date: 9 July 2015 at 15:43:04
To: [skim-app:bugs] 1019@bugs.skim-app.p.re.sf.net
Subject: [skim-app:bugs] #1019 Skim blocks emptying trash
--
Harald Hanche-Olsen
Institutt for matematiske fag
NTNU
7491 Trondheim
http://www.math.ntnu.no/~hanche/
Related
Bugs:
#1019This really is a system bug. And I really don't know what else I can possibly do to work around this than what we are now already doing. Apple is the onyl one that can fix this.
Yeah, I understood at the time that it was a system bug. But you found a workaround, though it took a long time, right? I don’t know any details, but thought perhaps something had happened in the code to disable the workaround. But if the problem is that the workaround is still there, but just doesn’t work anymore, it will be harder to do anything about it. Still, I thought it right to report it. Not expecting any miracles. 8-)
– Harald
The point is that this workaround is already applied, and it's all we can do. So if you again see it, it is an addition bug, whioch is more serious, and there won't be a workaround for that anymore, so Apple really is the only one who can solve it.
Finally was able to reproduce. This really does seem to be a system bug, where the PDFView and the PDFDocument seem to leave a retain cycle on 10.10. Breaking this cycle at cleanup time solves the problem. Fixed for the next release.