TextEdit se niega a modificar un archivo en /Users/Shared propiedad de otro usuario a pesar del modo 666

Tengo un archivo de texto en /Users/Shared que me gustaría que todos los usuarios de mi Mac pudieran editar. La ventana Obtener información muestra que todos tienen acceso de lectura y escritura, y cuando abro el archivo con TextEdit en una cuenta que no es del propietario, la barra de título no indica que el archivo esté bloqueado. Sin embargo, cuando intento guardar mis ediciones, me encuentro con las ventanas emergentes "El documento no se pudo [guardar / guardar automáticamente]. No tiene permiso".

Intenté agregar el usuario no propietario a la lista de permisos en la ventana Obtener información. No dados.

Salidas de ls(con nombres editados):

$ ls -l /Users/
total 0
drwxr-xr-x+ 14 Guest        _guest   476  7 Apr 11:14 Guest
drwxrwxrwt  45 root         wheel   1530 12 Apr 17:40 Shared
drwxr-xr-x+ 15 fileowner    staff    510 22 Feb 12:49 fileowner
drwxr-xr-x+ 17 admin        staff    578 21 Dec 10:55 admin
$ ls -l /Users/Shared/Links.txt 
-rw-rw-rw-@ 1 fileowner  wheel  619 25 Feb 19:44 /Users/Shared/Links.txt

Puedo reproducir este comportamiento en dos máquinas separadas, una que ejecuta 10.8 y la otra 10.9, pero no en la que ejecuta 10.6.

Respuestas (1)

Tenga en cuenta que la cadena de permisos para /Users/Shared termina con una 't'. Esto indica que el sticky bit está configurado para ese directorio. De acuerdo con "hombre 8 pegajoso",

 A directory whose `sticky bit' is set becomes an append-only directory,
 or, more accurately, a directory in which the deletion of files is
 restricted.  A file in a sticky directory may only be removed or renamed
 by a user if the user has write permission for the directory and the user
 is the owner of the file, the owner of the directory, or the super-user.

Sospecho que cuando TextEdit intenta guardar un archivo, primero intenta cambiar el nombre o eliminar el archivo anterior. Pero en un directorio con el sticky bit establecido, solo el propietario puede hacer esto. Por lo tanto, la falla basada en permisos.

Puede probar esto probando algo como esto como usuario Invitado

echo " " >> /Users/Shared/Links.txt

Si esto tiene éxito, muestra que el Invitado puede escribir en el archivo y que TextEdit debe cambiar el nombre o eliminarlo, no solo volver a escribir el archivo.

Bienvenido, nos gustan las respuestas detalladas como esta.
Su comando de terminal se ejecutó sin problemas, por lo que parece que la implementación de la versión de archivos desde 10.7 utiliza el cambio de nombre y/o (re)mover, en lugar de sobrescribir. ¡Gracias!
@Buscar: Gracias por la bienvenida. Me alegro de poder contribuir. epimorphic: Gracias por dejarme saber lo que pasó. Siempre es agradable escuchar que la idea de uno funcionó. :)