New File System in Tiger

On 10/5/2005 1:31 PM, "Denis Jarvis" <dbjarvispeak.org> spake thus:

> "One or more files were changed on disk, but were
> not loaded because they had unsaved changes"

This isn't particularly new to Tiger: BBEdit has been able update open
documents that have been saved by another application for quite some time
(since at least somewhere in the 7.x versions, possible earlier), and I have
definitely seen this error a few times under Panther when I wasn't paying
attention to what I was doing :)

Perhaps they've made this behaviour more global than it was previously?

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger

At 6:31 PM -0700 2005/05/09, Denis Jarvis wrote:
>Experimenting with Tiger, I was surprised by new file behavior. It
>seems that the old system of file locks has been replaced with a
>system based on inter-process signalling. In Tiger, if a file is
>opened for editing, it is not locked to prevent another program
>writing to it, as the following simple example shows.

        I think this change was to make Samba and Mac (AFP) locks
compatible. I believe I saw a mention of a WWDC track discussing it,
which I can't find now -- perhaps last year.


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

Denis Jarvis wrote:
> Experimenting with Tiger, I was surprised by new file behavior. It
> seems that the old system of file locks has been replaced with a
> system based on inter-process signalling. In Tiger, if a file is
> opened for editing, it is not locked to prevent another program
> writing to it, as the following simple example shows.
>
> ...snip...
>
> The file system, by allowing two programs to open the same file for editing,
> caused this conflict. These programs can deal with the file signals
> to help prevent data loss but not all programs can. In particular, if
> you place two Terminal windows side by side and in each use pico to
> edit the same file as above, then the saved file is not automatically
> read and there is no Warning Message. Instead the file exists as the
> last version saved.

There may be a change in file system behaviour, but I'm not convinced by
this demonstration. I believe you would find exactly the same behaviour in
10.3... and probably 10.2, 10.1, and 9.1, 8.0 and 7.5 too for that matter.
(You might have had to use BBEdit Lite in place of TextWrangler to
experiment on the older classic systems.)

Neither BBEdit nor TextWrangler (which comes from the same stable) nor
indeed many other programs keep files open. They open the file, read the
data into memory (or into various nefarious swap files) and close it; when
you save, they re-open the file, write the new version, and close it.
BBEdit has a nice feature (actually controlled by a preference) that if
de-activated (ie another app comes to the front) and then activated again,
it will check files on disk corresponding to open windows to see if they've
been changed since BBEdit last opened/saved them. If you've not made any
editing changes since then, and the file has changed on disk, it
automatically updates the open window. If you have this preference set, and
BBEdit notices the file on disk has changed, but you've also made changes,
it doesn't reload the file from disk - but instead gives the warning you
quote, since you might otherwise expect that you were looking at an
up-to-date copy of what's on disk. Evidently the same code is in
TextWrangler.

This is quite an unusual (but a very useful) feature; but it's implemented
very simply as described above, as far as I can recall has been working for
many years, through various classic versions of MacOS, and it has nothing to
do with inter-process signalling.

Equally your experiment with pico in the terminal would reproduce
identically in older versions of the OS: pico reads a file into memory and
closes it; edits in memory; then opens/writes/closes when you save. If you
attempt to save in both at (*exactly*) the same time, then I'd expect that
one of them would find it locked (in old and new OS's); but otherwise, I'd
expect the behaviour you report, each can blindly overwrite the other - and
it was ever thus.

Your Eudora experience is obviously a completely different kettle of
monkeys, and may indeed indicate a difference between Tiger and Panther (or
is it poosible that you've switched from using AFP to SMB filesharing?) -
but I very much doubt if there's any grand new scheme involving
inter-process signalling. (More likely something in Eudora that needs to
updated in some minor way?)

  Ben Rubinstein | Email: benr_mlcogapp.com
  Cognitive Applications Ltd | Phone: +44 (0)1273-821600
  http://www.cogapp.com | Fax : +44 (0)1273-728866

In my first email I described how, in my configuration where
potentially an application running on two Macs can access the same
file, the behavior of Eudora was different in Tiger compared with
Panther. Unfortunately, I speculated wrongly on what was happening
"under the hood". Nigel Stanger and Ben Rubinstein kindly set me
straight but the original problem remains.
<a href="/webx?13@@.3c639fc3/0">Nigel Stanger, "New File System in Tiger" #1, 10 May 2005 8:26 am</a>

A personal Mac with one user at a time and no file sharing, will
almost never provide a situation where two applications are
potentially writing to a common file. But, when there are multiple
Macs on a local network sharing files, conflicts can frequently occur
inadvertently. Applications should protect data integrity under these
circumstances. My problem is that changes in Tiger stopped Eudora
doing so.

My wife and I share two Macs, a Power Mac G4 and an iMac G5,
connected with AppleTalk personal file sharing over 100baseT
ethernet. Each runs a single account with the same name, uid and gid.
The G5 has a standard user file structure. The G4 file structure
contains several aliases to corresponding points in the G5 structure.
In particular Pictures, Music, Movies, Eudora Settings on G4 point to
the G5. This is a common configuration with unix workstations on a
local network. In our case it mirrors our requirements. We want one
library of family photos that we can both access. Much of our email
is common and so we want most of it easily accessed by both. Movies
is common mainly because only one drive has the 10s of GB available
and so acts as a file server. It seems to me that this configuration
is simple yet suitable and, indeed, for 6 months under Panther has
worked well.

With the Eudora failure, I decided to investigate how other
applications behaved on my configuration. I ran the same named
application on both Macs using one set of data on the G5. I was
surprised at the variety of behavior.

iPhoto 5.0.2 - Use on either, Safe from both.
The application will run on either Mac. If it is running on one and
then is activated on the second, it will get as far as displaying the
Library, but then issues a warning, "The iPhoto Library is locked, on
a locked disk, or you do not have permission to make changes to it."
and, on OK, this second iPhoto quits.

Pages - Unsafe as it can run on both when editing same file.
With Pages running on both Macs, each will quite happily open the
same file and Save after independent edits. Only the edits last saved
are retained and there is no indication that the other edits have
been lost.

Appleworks 6.2.9 - Use on either, Safe from both.
The application will run on either Mac. If it is running on one and
then activated on a second, it will issue one of the following
messages.
" An unexpected error occurred #-50" and quit.
"This file is locked or in use. Would you like to open a copy of it?"
if not it quits.

TextEdit 1.4 - Can use on both to edit same file but Safe from edit loss.
With application running on on both Macs, each will open the same
file and allow edits. However, after a Save on one a Save on the
other results in the message.
"The file has been changed by another application since you opened or
saved it. Saving might cause you to lose some changes. Save anyway?"
Instead, a Save As to a different file allows the changes to be
manually merged into the other file.

TextWrangler 2.0 - Can use on both to edit same file but Safe from edit loss.
Behavior as shown in previous email example.

BBEdit Light 6.1.2 - as TextWrangler
Note that this version of the application is dated October 2001.

Mail 2.0 - Safe but can use only on Mac containing data files.
The ~user/Library/Mail folder seems to be hard coded into the
application. It will not be deflected neither by replacing the folder
with an alias to the corresponding folder on the other Mac, nor by
editing the .plist.

Address Book 4.0 - Safe but can use only on Mac containing data files.
If the folder containing the address data files is replaced with an
alias, the application quits before completing start up.

Eudora 6.2.1 - Unsafe on Tiger as it can run on both from the same data files.
Under Panther, an attempt to activate on the other Mac results in
failure with a message to say the Settings file cannot be opened.
Under Tiger, this inhibition does not occur and with uncoordinated
saves to the data files, messages can be lost.

The above shows a very varied behavior from just a few of the
applications that might be used. I am not going the speculate again
on what the changes were in Tiger but, in any case, Eudora needs to
be changed to restore its Panther behavior and Pages needs to be made
safe. As a user, I would like Apple to specify what behavior we
should expect.

Denis Jarvis

At 12:17 AM -0700 2005/05/13, Denis or Janet Jarvis wrote:
>In my first email I described how, in my configuration where
>potentially an application running on two Macs can access the same
>file, the behavior of Eudora was different in Tiger compared with
>Panther. Unfortunately, I speculated wrongly on what was happening
>"under the hood". Nigel Stanger and Ben Rubinstein kindly set me
>straight but the original problem remains.
><a href="/webx?13@@.3c639fc3/0">Nigel Stanger, "New File System in
>Tiger" #1, 10 May 2005 8:26 am</a>
>
>A personal Mac with one user at a time and no file sharing, will
>almost never provide a situation where two applications are
>potentially writing to a common file. But, when there are multiple
>Macs on a local network sharing files, conflicts can frequently occur
>inadvertently. Applications should protect data integrity under these
>circumstances. My problem is that changes in Tiger stopped Eudora
>doing so.

        Interesting. This was broken for quite a while with the
initial Carbon releases of Eudora. I killed several Eudora Settings
files by launching two different betas of Eudora simultaneously
against the same Eudora Settings file. Glad to hear it's fixed.

>With the Eudora failure, I decided to investigate how other
>applications behaved on my configuration. I ran the same named
>application on both Macs using one set of data on the G5. I was
>surprised at the variety of behavior.

        As you imply below, this is implemented by each application,
so Apple can't simply fix it. I agree that Apple should provide
(human interface) guidelines on how to deal with multiple accesses to
files from single applications, though.

>iPhoto 5.0.2 - Use on either, Safe from both.

>Pages - Unsafe as it can run on both when editing same file.

        This is a flaw in Pages. If supported versions of Mac OS X
don't support locking in the preferred way, Pages could work around
this using a lock file (which is what UNIX services normally do).

>Appleworks 6.2.9 - Use on either, Safe from both.

        Good for Apple.

>TextEdit 1.4 - Can use on both to edit same file but Safe from edit loss.
>
>TextWrangler 2.0 - Can use on both to edit same file but Safe from edit loss.

>BBEdit Light 6.1.2 - as TextWrangler

        Yes, Bare Bones gets this stuff right.

>Mail 2.0 - Safe but can use only on Mac containing data files.
>The ~user/Library/Mail folder seems to be hard coded into the
>application. It will not be deflected neither by replacing the folder
>with an alias to the corresponding folder on the other Mac, nor by
>editing the .plist.
>
>Address Book 4.0 - Safe but can use only on Mac containing data files.
>If the folder containing the address data files is replaced with an
>alias, the application quits before completing start up.

        I suspect both of these will work if you use symlinks, but
haven't tried. Test "cd ~/Library; mv Mail Mail.local; ln -s
/Volumes/ServerMac/Users/dbjarvis/Library/Mail" or something like
that.

>Eudora 6.2.1 - Unsafe on Tiger as it can run on both from the same data files.
>Under Panther, an attempt to activate on the other Mac results in
>failure with a message to say the Settings file cannot be opened.
>Under Tiger, this inhibition does not occur and with uncoordinated
>saves to the data files, messages can be lost.

        Eudora's smart about aliases, from when the University
required support for storing the Eudora Folder on floppy disks or
file servers.

>The above shows a very varied behavior from just a few of the
>applications that might be used. I am not going the speculate again
>on what the changes were in Tiger but, in any case, Eudora needs to
>be changed to restore its Panther behavior and Pages needs to be made
>safe. As a user, I would like Apple to specify what behavior we
>should expect.

        Apple wouldn't really specify it to users, but to developers.
Yes, they definitely should.


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>