Re: OS X 10.7 and TextEdit creating new files vs. editing existing files
Re: OS X 10.7 and TextEdit creating new files vs. editing existing files
- Subject: Re: OS X 10.7 and TextEdit creating new files vs. editing existing files
- From: Jim Luther <email@hidden>
- Date: Mon, 15 Aug 2011 17:03:41 -0700
From another developer here at Apple:
> I'm not on that mailing list, so I can't respond, but here's the reasoning for what Steve is seeing:
>
> Under POSIX rules, a newly created file is supposed to inherit the group (and ACLs) of its parent. NSDocument's safe saving causes files to inherit the user's gid instead, since the file is created in the user-owned temporary directory. There were many complaints about this, so I fixed this for newly created files by ensuring that we write directly to the destination directory if the user's gid and the destination gid differ (or if there are any inheritable ACLs). (We don't do this generally yet, because there's currently no safe way to avoid Finder flickering if we write the temporary file to the side of the original.)
I don't know if that helps explain the issue or not.
On Aug 15, 2011, at 4:44 PM, Steve Goddard wrote:
> Hello again,
>
> The issue I described below, with TextEdit and creating new files is prevented from updating due to the sandboxd preventing some reads, all write access (so no updates work or auto-save succeed).
>
> So the Sandboxed Applications feature is what is causing my issue. From debugging through the source available, I see callbacks made to the registered mac_policy modules (Sandbox being one) for various file IO requests which in the case of Sandbox callback returns an EPERM error.
>
> Anyone have any ideas, why, even when as the user, selects my file systems mount point and file location to create the file, that seems to be insufficient to make things work (give TextEdit the entitlement to write to that file in that directory)?
> SMB shares seem to work fine. Are there any file system capabilities or such that would cause Sandbox to say that the location is not trusted?
>
> The messages I see in the logs are of the the type:
>
> Aug 12 13:58:53 promb-1s-dhcp133 sandboxd[4280] ([4237]): TextEdit(4237) deny file-write-mode /Volumes/VMware Shared Folders/folder/new.rtf
> Aug 12 13:58:53 promb-1s-dhcp133 sandboxd[4280] ([4237]): TextEdit(4237) deny file-write* /Volumes/VMware Shared Folders/folder/new.rtf
> Aug 12 13:58:53 promb-1s-dhcp133 sandboxd[4280] ([4237]): TextEdit(4237) deny file-issue-extension /Volumes/VMware Shared Folders/folder/new.rtf
>
> The file is created 644 permissions for that user and the folder has 777. So all these failures seem to be due to the Sandboxing of TextEdit.
>
> Thanks for any suggestions or help.
> Steve
>
>
>
> ----- Original Message -----
>> From: "Steve Goddard" <email@hidden>
>> To: email@hidden
>> Sent: Monday, August 1, 2011 5:16:02 PM
>> Subject: OS X 10.7 and TextEdit creating new files vs. editing existing files
>>
>> Hi there,
>>
>> I am debugging an issue with TextEdit and our file system.
>> New files created with TextEdit are not handled correctly. However,
>> editing existing files work fine.
>>
>> The difference in behavior seems to occur with how the temp files are
>> handled and then the original file updated.
>> Note: the root directory of our mount is always read only.
>> I have seen with existing files, and SMB mounts, that TextEdit tries
>> to create and use a ".TemporaryItems" folder in the root folder of
>> the mount. However, since that fails, TextEdit creates a temporary
>> folder such "targetfilename.sbSomething" in the target directory and
>> then creates the updated file in that temporary folder, followed by
>> a rename after deleting the original file to update. This sequence
>> is followed for all successive updates to the file while the user is
>> editing.
>>
>> This behavior is fine and is the same for SMB shares (with root
>> folder as read only).
>>
>> However, when TextEdit creates a new file and stores it through our
>> file system, the behavior changes. It does not look for or try and
>> create the ".TemporaryItems" folder or even a temporary folder in
>> the target directory. Initially, it creates the new file with any
>> input that is in the buffer immediately in the target folder with
>> the target file name. No temporary folder or file is created. When I
>> go to add more changes and save, I get an error when it fails an
>> open on the target file for read only access with EPERM. I am not
>> sure why that is returned and not seen an error in the logging from
>> my file system for that.
>>
>> However, can anyone shed any light on why TextEdit would behave
>> differently in this case? Is it due to the volume attributes or
>> something?
>>
>> Thanks.
>> Steve
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Filesystem-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Filesystem-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden