Re: Is a file open in another application?
Re: Is a file open in another application?
- Subject: Re: Is a file open in another application?
- From: Steve Bird <email@hidden>
- Date: Sun, 20 Mar 2011 10:11:38 -0400
On Mar 20, 2011, at 9:28 AM, Brad Stone wrote:
> After sleeping on it my choices are to remove the encryption feature or make a big ugly dialog box warning the user if they encrypt a file that's open they will lose their changes. Neither of these approaches are optimum.
Are you sure you need a dialog? Such behavior is not exactly unexpected.
Make a folder.
Make a PAGES file in that folder.
The file contains "BEFORE CHANGES".
Save it.
Change the text to "AFTER CHANGES", but don't SAVE it.
Go to finder.
COMPRESS the folder.
The compressed version contains the BEFORE CHANGES text, exactly what I would expect.
I'm assuming WORD would parallel PAGES here, and ENCRYPT would parallel COMPRESS, but that behavior seems appropriate without warnings.
>
> On Mar 19, 2011, at 11:04 PM, Brad Stone wrote:
>
>> I do need it to work for any app, not just Word or XL.
>>
>> I guess a poor workaround would be since it's not possible to reliably check if the file is open I can force the user to quit the file's default app before allowing them to encrypt. It's just kind of heavy-handed.
>>
>> On Mar 19, 2011, at 6:20 PM, Charles Srstka wrote:
>>
>>> On Mar 19, 2011, at 1:40 PM, Conrad Shultz wrote:
>>>
>>>> On 3/19/11 11:10 AM, Kyle Sluder wrote:
>>>>> On Sat, Mar 19, 2011 at 9:13 AM, Conrad Shultz
>>>>> <email@hidden> wrote:
>>>>>> Note that this will only capture files that are properly opened (i.e.
>>>>>> fopen()'d), so you won't catch every apparently open file. For example,
>>>>>> if you open a file in vi(m), it creates a hidden scratch file in the
>>>>>> same directory and closes the original file. You then edit the scratch
>>>>>> file, which is only written out to the original file on save. In this
>>>>>> way, the original file is protected from damage due to a crash, but lsof
>>>>>> will almost never show it as being open.
>>>>>
>>>>> This is also how Cocoa apps work. They only keep the file open to read
>>>>> its contents.
>>>>>
>>>>> I'm afraid that what Brad wants to do is not possible yet.
>>>>
>>>> Are you certain that is a general behavior?
>>>
>>> Just looking at NSDocument’s default hooks for opening/saving files will show you the answer to that. The ones the user is encouraged to use in the general case read the file into an NSData object on open, and write an NSData out to the file on save.
>>>
>>> Charles_______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
----------------------------------------------------------------
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
www.Culverson.com (toll free) 1-877-676-8175
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden