On Jul 9, 2012, at 11:51 AM, Nathan Sims wrote:

> On Jul 9, 2012, at 11:18 AM, Macs R We wrote:
>> 
>> On Jul 9, 2012, at 10:04 AM, LuKreme wrote:
>> 
>>> On Jul 7, 2012, at 16:35, "Dinse, Gregg (NIH/NIEHS) [V]" 
>>> <[email protected]> wrote:
>>>> I have one other question.  If the PDF is not open, then why should I not 
>>>> be able to delete it, regardless of whether or not the Preview app is 
>>>> running?  In the past, I thought this was possible, at least most of the 
>>>> time, but now it seems that it hardly ever (if ever) is possible.
>>> 
>>> I think the short answer is because preview may have made changes to the 
>>> PDF before it quit. Until preview actually launches again and closes the 
>>> file, the system doesn't know if it's safe to delete it.
>> 
>> This implies that any time OS X implicitly terminates an app, it potentially 
>> leaves all the files that were open in an inconsistent state, inaccessible 
>> by anything else.  This flies in the face of a half century of OS design.  
>> When people get errors trying to open file A from app X because file A was 
>> open in app Y three days ago, you don't want to be the guy working the call 
>> center.
> 
> A file is "open" only when a process has a (kernel) stream to the file's 
> inode. When a process dies, all of its open files are closed by the kernel 
> because the kernel closes the process's open streams as part of process 
> rundown. The Trash subsystem does not receive any such "notification". When 
> you empty the trash, it tries at that time to perform a unlink() on the file. 
> If there is a stream associated with the file it cannot be closed until the 
> owner of the stream (the process that opened a stream to it) closes the 
> stream either by: a) an explicit close() or b) an implicit close() done on 
> its behalf by the kernel via process rundown.
> 
> An application's streams can linger when it is waiting for pending I/O to be 
> completed by the file system. In this case the app may not appear in Activity 
> Monitor, but as a zombie process in lsof. See errno's EBUSY.

This is all true on the Darwin level, but there is some extra voodoo associated 
with the Trash subsystem.  From the Terminal, the file can be rm'ed with no 
complaint at all, meaning the underlying OS is happy and all streams are 
closed.  But there is some extra bookkeeping going on at the Locum level, which 
is failing.

-- 
 Macs R We -- Personal Macintosh Service and Support
   in the Wickenburg and far Northwest Valley Areas.
                           http://macsrwe.com

_______________________________________________
MacOSX-talk mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/macosx-talk

Reply via email to