Possible to allow READ & WRITE but not Delete?

Discussion in 'macOS' started by Lincoln 6 Echo, Feb 27, 2006.

  1. Lincoln 6 Echo macrumors member

    Joined:
    Nov 29, 2005
    #1
    Hi, just wondering is it possible to allow READ & WRITE but not Delete? I know sounds maybe weird and maybe it's an oxymoron.

    I would like to be able to read and write to a Main folder and it's subfolders, BUT I want to make sure that Main folder (and it's contents) is not accidentally put in the trash. Usually, when I delete something, I empty the trash immediately using shortcut keys... so it occurred to me I could accidentally delete something pretty quickly... and that could be bad.

    Anyone know if it's possible to set up a folder like this?
     
  2. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #2
    Maybe if you used Butler or QuickKeys to create a keyboard shortcut that would move a file to a specified folder that you set up and then you could delte as normal from there.. otherwise, no I don't think so if I understand what you're asking for.

    By virtual of allowing "write" you're allowing edit, of which delete is a part of.
     
  3. plinkoman macrumors 65816

    plinkoman

    Joined:
    Jul 2, 2003
    Location:
    New York
    #3
    why don't you just not delete stuff without checking the trash bin first?

    when i delete stuff, i leave it in the trash bin, and i go through and empty trash about once a week checking everything first. when it's big stuff, i'll open the trash bin and have a look and delete it right a way, but i always take the extra 5 seconds to check, and i have yet to accidentally delete anything. ;)
     
  4. mrichmon macrumors 6502a

    Joined:
    Jun 17, 2003
    #4
    You can set up a folder so that the files within the folder can be read and written, but the files cannot be deleted. However, this also will mean that the permissions will not allow files to be added to the folder unless you rely on user and group identities to allow the owner user or owner group of the folder to create and delete files in the folder while other users cannot create or delete files.
     
  5. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #5
    How? Immuable flag?
     
  6. Seasought macrumors 65816

    Seasought

    Joined:
    Nov 3, 2005
    #6
    Why not set up a symbolic link to the Main folder? Perhaps this is what you are looking for.
     
  7. ElectricSheep macrumors 6502

    ElectricSheep

    Joined:
    Feb 18, 2004
    Location:
    Wilmington, DE
    #7
    You can do this under MacOS X 10.4.x by enabling Access Control Lists, and by using the command line to assign ACL values to the folder.

    In a terminal window, enabled ACLs with the following command:

    sudo /usr/sbin/fsaclctl -p / -e

    ACLs are group and user based policies. You'll have to do some thinking to figure out how you want to assign privileges. Do you want to assign them by a whole group, or on an individual user basis?

    If you are just dealing with a single user, use commands like this:

    chmod +a "johndoe allow read,write" /path/to/folder
    chmod +a "johndoe deny delete" /path/to/folder

    The effect of these two commands will be to allow user johndoe to add files and remove files from /path/to/folder, but he will not be able to delete /path/to/folder.

    see man chmod for a complete listing of what properties you can apply ACL restrictions to.

    Unfortunately, ACLs are not preserved if you use the standard archiving features incorporated into MacOS X. I am also not aware of any GUI-based applications that will simplify the process of managing ACLs on files and folders, save for the Workgroup Manager that comes with MacOS X Server.
     
  8. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #8
    Fantastic! I didn't know there was an ACL concept in Tiger. Thanks for the tip!
     
  9. mrichmon macrumors 6502a

    Joined:
    Jun 17, 2003
    #9
    No, the key is that creating and deleting a file is a change to the directory. But reading and writing a file are operations on a file.

    So, you can create a directory foo and create some files fileA.txt and fileB.txt in that directory. Then set the permissions as follows:

    Code:
    dr-x------    foo
    
    -rw-------    foo/fileA.txt
    -rw-------    foo/fileB.txt
    
    The lack of write permission on the directory means that the contents of the directory cannot be changed. That is, you cannot remove fileA.txt or fileB.txt and you cannot add new files to the directory. However, the permissions on the fileA.txt and fileB.txt determines what can happen to those files.
     
  10. Seasought macrumors 65816

    Seasought

    Joined:
    Nov 3, 2005
    #10
    This pretty much nails it. I learned something new. :)
     
  11. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #11
    Hmm.. well I guess if you try and delete something, it asks you for authentication thru the Finder. However, you can't copy anything into that folder without the same issue, which seems to defeat what the OP wanted. So I guess this is technically one way to do it, but far from smooth.
     
  12. mrichmon macrumors 6502a

    Joined:
    Jun 17, 2003
    #12
    I specifically pointed out that it would not allow people to add to the folder. It wasn't clear to me that the OP was wanting to add to the folder, or whether they wanted to share files that multiple users could read and write without deleting.
     
  13. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #13
    I interpreted what the OP wanted in a different way.

    But you CAN add new files to the directory.. one just has to authenticate every time. But it'll have to be all done via the Finder, trying to do it from a save dialogue within an app doesn't prompt one for authentication.

    Again, as I was pointing out, what you proposed would work as a solution that I interpreted the OP wanted, it's just far from smooth. "Smooth" being for the OP's benefit, not yours.
     
  14. mrichmon macrumors 6502a

    Joined:
    Jun 17, 2003
    #14
    Opps. I only quickly verified the behavor by accessing the files directly using terminal commands and assumed the higher-level behavior would follow as it does on other BSD systems.

    Save dialogs not requiring authentication in this case would appear to be a bug in the Cocoa frameworks since the save dialog is ignoring the file system permissions set on the directory (and violating the defined permission semantics).
     
  15. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #15
    Oh.. that's a poorly worded posting on my part.. what I meant was that in my limited testing I was unable to save to that directory via a save dialogue because I was not able to be prompted for authentication..

    As far as permissions go, it's working as it is intended.
     
  16. mrichmon macrumors 6502a

    Joined:
    Jun 17, 2003
    #16
    Ok great. Now that we've both butchered the language in our confusion, at least Apple is on top of their game. :)
     
  17. theBB macrumors 68020

    theBB

    Joined:
    Jan 3, 2006
    #17
    uappnd

    I recently came across a UNIX hint at macosxhints website, which might be exactly what you want. It turns out there is another way to lock files or folders other than access control lists, the usual read, write & execute priviledges.

    Here is an excerpt: "If the uappnd flag is set on a folder, new files may be added to that folder, but the files in that folder cannot be renamed and no files may be removed from the folder." I have not tried this flag on a folder myself, but this might let you edit the files inside the folder, as long as you don't try to remove, delete or rename them. If that's what you want, you can find more details on:

    http://www.macosxhints.com/article.php?story=20031017061722471
     

Share This Page