From: Christiaan H. <cmh...@gm...> - 2007-06-05 13:53:45
|
On 5 Jun 2007, at 3:37 PM, Adam R. Maxwell wrote: > > On Jun 5, 2007, at 04:23, Christiaan Hofman wrote: > >> >> >> On 6/5/07, Christiaan Hofman <cmh...@gm...> wrote: >> >> >> On 6/5/07, Adam R. Maxwell < ama...@ma...> wrote: >> >> On Monday, June 04, 2007, at 04:03PM, "Christiaan Hofman" >> <cmh...@gm... >>> wrote: >>> On 6/5/07, Adam R. Maxwell <ama...@ma... > wrote: >>>> >>>> >>>> On Monday, June 04, 2007, at 03:43PM, "Christiaan Hofman" < >>>> cmh...@gm...> wrote: >>>>> When the file is deleted, the kqueue notification is broken. So >> some >>>>> atomic writing processes can give problems. How can this be fixed? >>>>> Should there be a timier for this case? >>>> >>>> I'm not sure how many ways it can break, but I tried this: >>>> >>>> 1) run LaTeX on test.tex from TextMate, opens test.pdf in Skim >>>> 2) in Terminal, rm test.pdf >>>> 3) switch back to Skim; proxy icon for test.pdf is now gone, but >> the >>>> window is still there >>>> 4) switch to TextMate, run LaTeX again, and the window for the >> deleted >>>> test.pdf comes to the foreground >>>> >>>> I'm not sure how to handle that case. The kqueue notification is >> removed >>>> now when the file is deleted or renamed, but it seems like the >> "open POSIX >>>> file" in displayline isn't handled correctly by >> NSDocumentController, since >>>> (IMO) it should be opening the newly created test.pdf file. Just >> renaming >>>> test.pdf to test2.pdf and then re-running latex works as I >> expected, >>>> though. >>>> >>>> Adam >>> >>> >>> Opening a file shouldn't do anything if the file is already open, >> even if >>> the file has been updated. That's just normal opening procedure of >>> documents. So I do think this behavior is basically correct. Also >> because >>> the script doesn't know about updates. >> >> That doesn't seem like expected behavior to me. If I delete a file >> and then switch to Skim, the window no longer has a proxy icon, so >> presumably no longer has a path on disk; if you hit cmd-s, it says >> the location can't be determined. >> >> If I recreate a file on disk at the same path and then tell the app >> to open it using the full path, I expect it to open the new file, >> not switch to the window for a file that it just told me no longer >> exists. Preview does the same thing, but it seems broken. >> >> Generally it is. Remember, Skim is a viewer, so it views what you >> have loaded. This is the way open document works. Also if you open a >> document e.g. by double-clicking. It does not change to a changed >> file. So it is standard NSDocument behavior. >> >> Sorry, I mixed up some the different situations here. >> >> Deleting the file on disk indeed makes NSDocument lose its >> connection to any file. So I guess we should also not try to watch >> it for updates in this case, and remove it from the kqueue. > > It should be removed from the kqueue at that point. I didn't have > time yesterday to mess with it any more, though, and I wasn't sure > about save-as and save-to behavior. > That was already done by you, so that's OK now. I fixed the save/save- as behavior by temporarily removing it from the kqueue while those are busy. Save-to shouldn't do anything, as this is not supposed to do anything related to the file, either in the document and on disk. If it overwrites the file on disk, it will just trigger an update notification, I think that's OK. But we should check if it does not lead to a crash if Auto was selected, because the export process might not be finished (EAs) when the files is automatically reloading the exported file. >> Moving the file on disk /is/ noticed by NSDocument, though with a >> delay (e.g. when you select the window). So I think we should try to >> watch the moved file. I'm not sure how, perhaps we could do that in - >> setFileURL, because that is called when the document notices the >> change on disk. > > Ah, I don't think I tried that. I tried re-adding it after a delay in > the move/rename handler, but that only worked if I clicked on the > document first. I do agree that it should be watched automatically > (although clicking Auto again isn't too painful). > It's now re-added in setFileURL, which is the moment taht the document notices (and also updates the fileName). > If this kqueue business is too much hassle, I won't argue against > reverting to a timer, either. > I think it now works pretty well, and reload immediately after the file is changed. >> Overwriting a file on disk is not noticed by NSDocument. By default >> we should also not do that. The AS open command (or any file open >> command) should not reload the file when it is already open and the >> file on disk has changed. It can lead to data loss! Reloading the >> (changed) file from disk is the responsibility of our file update >> checking mechanism, and only that. > > Definitely! That's the autoReload BOOL ivar, right? I actually have > to write this week, so I'll be testing BibDesk and Skim. > > -- > Adam Also the autoreload pref itself. Christiaan |