Mac OS X Tiger to support Fast Logout and Autosave, Access Control Lists

Posted:
in macOS edited January 2014
According to sources privy to pre-release builds of Apple's Mac OS X 10.4 "Tiger" operating system, the release will feature "Fast Logout and Autosave" technology and support for Access Control Lists file-based permissions, AppleInsider has learned.



Fast Logout and Autosave



Fast logout and autosave is a performance-related feature designed to improve the user experience of Mac OS X Tiger.



Presently, closing windows in Mac OS X an expensive operation, especially if the application must prompt the user about unsaved changes for each document window. Tiger's fast logout and autosave feature will improve logout, shutdown, and restart operations by reducing the number of confirmation dialogs presented to the user, all the while protecting the user's unsaved data in open applications.



During a logout, shutdown, or restart operation, Tiger will determine whether an application should post a confirmation dialog for unsaved changes or perform an auto-save event. If the application performs an auto-save event, data will be saved to a special location on the system and the user will be logged out of Mac OS X. The next time the user logs in, the system relaunches each application with auto-saved documents and reconstructs the documents as their state immediately before the last logout.



According to sources, most of the applications that will ship with Tiger will already support Fast Logout and Autosave. On the other hand, third party developers will need to update their applications to gain the benefits of the new feature.



Access Control Lists



Tiger will also introduce support for Access Control Lists (ACLs)?a robust system for implementing file-based permissions that offer many improvements over the existing BSD permissions currently used by the Mac OS X file systems.



Among the improvements delivered by ACL's is support for ownership of files and directories by a group, enhanced interoperability with Samba and Windows, and support for multiple owners of a file or directory, each with potentially different permissions.



Additionally, ACL's will add support for static inheritance of file permissions from a parent directory and provide more control over a file than just read/write/execute permissions.

ACLs are a common feature of enterprise computing because they provide flexible and highly configurable rights management for servers. The technology also removes many of the limitations of the existing BSD permissions by allowing access to files and directories by multiple groups and users. In addition, it lets the system administrator grant specific rights to each user and group without requiring the creation of special new groups.
«1

Comments

  • Reply 1 of 25
    Yay for ACL support! I've been waiting for Apple to upgrade the permissions system, and adding ACLs seems like the perfect way to do it.
  • Reply 2 of 25
    So ACL are better than Mac OS X's current file permission system?
  • Reply 3 of 25
    Quote:

    Originally posted by MPMoriarty

    So ACL are better than Mac OS X's current file permission system?



    Yes, absolutely. ACLs allow for much more permissions customization than is possible with the current system. For example, an ACL can allow a file to be owned by more than one group - something not possible with the current system.
  • Reply 4 of 25
    hmmfehmmfe Posts: 79member
    Hurrah for ACLs. I hope this is evidence of a serious effort on Apple's part to create a server and client OS that can funtion in most small to mid-sized businesses. For the most part, they are there already. ACLs were big on my list as the current permissions were too restrictive. Now, make mounting of shares easier (more intuitive) and we've got a winner on the OS side.



    It is funny, I read that 2003 Small Business Server is a huge hit. Personally, I think it is horrible (although I find 2003 Server a fine OS). Apple has all the right parts; with a little polish it could compete very well with SBS2003.



    I guess I'm still smarting over my company's decision to ditching Panther Server/ OS X in favor of SBS2003/ XP...
  • Reply 5 of 25
    I wonder if Apple is going to have to enhance the GET INFO panel to adjust for ACL settings.
  • Reply 6 of 25
    dstranathandstranathan Posts: 1,717member
    Does the current Tiger Beta have any signs of ACLs?
  • Reply 7 of 25
    sjksjk Posts: 603member
    Quote:

    Originally posted by AppleInsider

    ACL's will add support for static inheritance of file permissions from a parent directory and provide more control over a file than just read/write/execute permissions.



    Sounds like that inheritance can work like a per-directory umask, probably obviating the need for the seriously limited global umask. Cool.



    What I'd really like is an automatic way to ensure consistent file permissions when installing software. Too many third party apps are installed with world writable directories, as running "find /Applications -type d -mode 777 -ls" will reveal.
  • Reply 8 of 25
    zzenzzen Posts: 9member
    I would just like to clarify that:



    a) the old file permissions (4byte 7777-style) are not BSD file permissions but rather general UNIX file permissions



    b) FreeBSD (and possibly other BSDs?) feature ACL for quite a while now



    It's quite probable that the Tiger ACLs are actually fetched from FreeBSD in my opinion. Especially since Jordan K. Hubbard is at Apple.
  • Reply 9 of 25
    Quote:

    Originally posted by zzen

    I would just like to clarify that:



    a) the old file permissions (4byte 7777-style) are not BSD file permissions but rather general UNIX file permissions



    b) FreeBSD (and possibly other BSDs?) feature ACL for quite a while now



    It's quite probable that the Tiger ACLs are actually fetched from FreeBSD in my opinion. Especially since Jon K. Hubbard is at Apple.




    Don't you think Apple should have put ACL support in Panther, then, if ACLs were available from *BSD?
  • Reply 10 of 25
    zzenzzen Posts: 9member
    Quote:

    Originally posted by wrldwzrd89

    Don't you think Apple should have put ACL support in Panther, then, if ACLs were available from *BSD?



    Well, yes and no. As far as I can tell, ACLs are part of FreeBSD since version 5.0, which was released in January 2003. (The current version is 5.2.1)



    It wasn't a newest thing under the sun at that time, but the FreeBSD implementation was quite fresh and Apple was left with about half a years time to copy it to Darwin. Which is not much. A safer and better strategy is to wait and see how the FreeBSD implementation lives up, wait for one or two versions before the bugs get ironed out and then introduce it into Darwin. And leave ample time for testing and debugging, since an error in the file permissions implementation could be very fatal.



    The question is why didn't they put ACLs in one of the incremental updates like 10.3.5. First of all, I am not sure if/how many apps the ACL will or will not break (probably just some disk maintenance apps), second, I guess they like to keep all the aces for paid upgrades.
  • Reply 11 of 25
    ACLs require both kernel support and support in the userland applications. Kernel support is probably fairly straightforward. Well, actually, maybe not so straightforward depending on how amenable HFS+ is to ACLs.



    However, updating all the commmand-line and GUI tools, as well as any frameworks or other-more-than-bare-UNIX APIs to support ACLs is a lot of work.
  • Reply 12 of 25
    Quote:

    Originally posted by nguyenhm16

    ACLs require both kernel support and support in the userland applications. Kernel support is probably fairly straightforward. Well, actually, maybe not so straightforward depending on how amenable HFS+ is to ACLs.



    However, updating all the commmand-line and GUI tools, as well as any frameworks or other-more-than-bare-UNIX APIs to support ACLs is a lot of work.




    Thanks for the info zzen and nguyenhm16. I guess Apple made the right choice by waiting until Tiger to deploy ACL support.
  • Reply 13 of 25
    rokrok Posts: 3,519member
    okay, getting off of ACLs for a second, i had a sudden realization with regards to the fast logout mentioned above, when combined with the better .mac syncing mentioned earlier this week...



    what if you could combine the two to sync your current SESSION with .mac. that way, when you went to ANY other mac, or your home mac, provided you have the same software installed there, you could choose "resume session closed on "name_of_mac_here" as of "time_date"?) then you could either just start your own home session, or you could seamlessly resume your work right where you left off.



    this type of seamless "any station is my station" has typically been reserved for the closed high-speed, central server network system. but what if apple brought it right home to the common person? no more backing files up to disk, or manually copying them to idisk, or emailing them home for further work... just encrypt it and logout of your workplace work, and your mac, mac os x and .mac handle everything else. heck, throw in a "remote desktop express" for only one-to-one linkup between two computers, and you never have to be away from your data...



    mind you, i don't really WANT something to make it easier to work at home AND work, but i find i keep doing it, so why not make it easier???
  • Reply 14 of 25
    hmurchisonhmurchison Posts: 12,419member
    Very cool idea Rok. I hope we head in that general direction.
  • Reply 15 of 25
    zzenzzen Posts: 9member
    Quote:

    Originally posted by rok

    what if you could combine the two to sync your current SESSION with .mac. that way, when you went to ANY other mac, provided you have the same software installed there, you could choose "resume session closed on "name_of_mac_here" as of "time_date"?



    Well, rok, as much as it sounds really cool, I don't think that's ever going to be possible, not without a MAJOR rewrite of the whole OS. There is a reason why this feature is limited to "high-end central server systems" as you write -- you boot the client always off the server and you can guarantee the same available resources (applications, disks etc.)



    First, the way I suppose fast logout will work:

    1) it will make a list of running applications

    2) it will tell each of the applications to return the list of unsaved documents

    3) for each of the documents, it will tell the respective application to compute a difference between the actual state of the document and the last saved copy on the disk. These differences will be store in a folder and upon the next login, all those respective applications will be opened and told to reconstruct the current document from the on-disk copy and the difference saved in the session.



    Let's see. If you would allow to synchronize between more computers, here are a few problems



    * You never have the same applications installed. Never. Not the very same version, configuration, plugins, exact same preferences, kernel extensions etc.



    * You have an iMovie project opened. You fast-logout. A few tens of megabytes are written to disk as the difference. You go to work, resume the session -- and expect to have the whole 2gigabyte project accessible?



    Or if you have a huge Photoshop file opened? Or DVD project?



    I think you see where I am heading. You need to share the same physical disk space (or synchronize the whole disk structure) in order for these sessions to work. I don't think it's possible otherwise.
  • Reply 16 of 25
    kim kap solkim kap sol Posts: 2,987member
    zzen brings good points...some of which I was about to mention.



    I think a safer bet would be Home on iPod.



    Bring iPod to work, plug iPod in, user shows up in user list, pick user, work, Fast Logout, unplug iPod, bring iPod home, plug iPod in, user shows up in user list, pick user, work.



    There's still an issue of not having the app or the exact version of the app in question...but I think it could work if the app was on the iPod and that app superseded other apps in priority launching order.
  • Reply 17 of 25
    zzenzzen Posts: 9member
    Quote:

    Originally posted by kim kap sol

    I think a safer bet would be Home on iPod.



    Of course you can still tell iMovie to save your 2GB project somewhere outside of your Home (and thus the iPod) so the problem stays the same.



    I really can't envision any other way than complete HD structure syncing.
  • Reply 18 of 25
    rokrok Posts: 3,519member
    Quote:

    Originally posted by kim kap sol

    zzen brings good points...some of which I was about to mention.



    I think a safer bet would be Home on iPod.



    Bring iPod to work, plug iPod in, user shows up in user list, pick user, work, Fast Logout, unplug iPod, bring iPod home, plug iPod in, user shows up in user list, pick user, work.



    There's still an issue of not having the app or the exact version of the app in question...but I think it could work if the app was on the iPod and that app superseded other apps in priority launching order.




    you may be right, but assuming the large ipod just keeps getting a larger and larger hard drive, isn't it theoreticallly possible to also carry around a copy of your apps to use as well? the only drawback to that idea would be that the ipod isn't really meant for sustained disk usage. but if the apps could be loaded to a temporary ram disk from the ipod on any machine other than your main one, which then gets ditched on logout... but then you'd only have seveeraal gigs of ram disk to work with in that scenario.



    ah hell, perhaps it's a pipe dream, but i have to say i like the IDEA of it, anyway... steve, MAKE IT HAPPEN.
  • Reply 19 of 25
    murkmurk Posts: 935member
    I haven't heard any other mention of Autosave in Tiger besides the AI article. Is it actually included?
  • Reply 20 of 25
    Quote:

    Originally posted by murk

    I haven't heard any other mention of Autosave in Tiger besides the AI article. Is it actually included?



    Yes, I agree that it's odd we haven't heard much more about these features. Maybe someone with a Tiger build could enlighten us.



    Mike
Sign In or Register to comment.