From: Rowland McDonnell on
Tim Streater <timstreater(a)waitrose.com> wrote:

[snip]

> I didn't think we did paths in OS X.
[snip]

I don't know the details of this sort of thing, but:

Paths and filename extensions used to be more or less irrelevant from
the point of view of the MacOS *before* MacOS X.

(and if you had an original Mac with the MFS filing system, you actually
had a completely flat filing system - folders weren't directories,
merely a convenience for the user and invisble to the actual filing
system as such. You can look up when HFS appeared as easily as I can, I
suspect...)

Filename extensions are now the only way MacOS X 10.6 works out what to
do with a file (boo, hiss).

And I'd not be surprised if, by the same token, paths are now
significant to this and that. Certainly they are when dealing with some
`normal' Unix software ported to Macs that I've used on OS X.

Rowland.

--
Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org
Sorry - the spam got to me
http://www.mag-uk.org http://www.bmf.co.uk
UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
From: David Empson on
Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote:

> Tim Streater <timstreater(a)waitrose.com> wrote:
>
> [snip]
>
> > I didn't think we did paths in OS X.
> [snip]
>
> I don't know the details of this sort of thing, but:
>
> Paths and filename extensions used to be more or less irrelevant from
> the point of view of the MacOS *before* MacOS X.
>
> (and if you had an original Mac with the MFS filing system, you actually
> had a completely flat filing system - folders weren't directories,
> merely a convenience for the user and invisble to the actual filing
> system as such. You can look up when HFS appeared as easily as I can, I
> suspect...)

The Mac OS X Finder has changed the user interface to be based around
the concept of a browser, and it supports features like column view
(which are explicitly based on absolute paths), so it doesn't surprise
me if open windows exhibit this behaviour. The window is effectively
showing a file:/// URL, and part of the URL no longer exists.

> Filename extensions are now the only way MacOS X 10.6 works out what to
> do with a file (boo, hiss).

The file type is still supported, you can assign individual files to
specific applications, and there are mechanisms based on other metadata
attached to files (details of which elude me at present). The only
change in 10.6 in this area is is that the creator code is ignored.

Even that one change is enough for me to agree with you on the "boo,
hiss" front.

> And I'd not be surprised if, by the same token, paths are now
> significant to this and that. Certainly they are when dealing with some
> `normal' Unix software ported to Macs that I've used on OS X.

There is a difference in behaviour between Mac-specific aliases (which
are used in alias files and internally by many applications), and
text-based pathnames (used in symbolic links, which are common in Unix).

Aliases to files on an HFS or HFS+ volume can track a file or folder as
it moves around within a volume or it or any parent is renamed, by
referencing the unique file ID, parent folder ID and other clues. It
only reverts to behaving like an absolute pathname if the file or a
parent is deleted.

Symbolic links reference an absolute path and won't follow a file or
folder which is renamed or moved.

--
David Empson
dempson(a)actrix.gen.nz
From: Rowland McDonnell on
David Empson <dempson(a)actrix.gen.nz> wrote:

> Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote:
>
> > Tim Streater <timstreater(a)waitrose.com> wrote:
> >
> > [snip]
> >
> > > I didn't think we did paths in OS X.
> > [snip]
> >
> > I don't know the details of this sort of thing, but:
> >
> > Paths and filename extensions used to be more or less irrelevant from
> > the point of view of the MacOS *before* MacOS X.
> >
> > (and if you had an original Mac with the MFS filing system, you actually
> > had a completely flat filing system - folders weren't directories,
> > merely a convenience for the user and invisble to the actual filing
> > system as such. You can look up when HFS appeared as easily as I can, I
> > suspect...)
>
> The Mac OS X Finder has changed the user interface to be based around
> the concept of a browser,

You wot?

The `concept' is just what it always was, from what I can tell.

I recall quotes from Apple bods say that they couldn't understand why MS
was moving towards a `browser' type interface for its `Finder-stand-in'.

I don't think you're at all right on this.

> and it supports features like column view
> (which are explicitly based on absolute paths),

Eh? NThey are based on files, surely? - they show you the path to the
file. It's based on the filing system, and the column view is simply a
convenience for the user which could just have well have been
implemented with System 7.

Or so it seems to me.

> so it doesn't surprise
> me if open windows exhibit this behaviour.

Which behaviour do you mean?

> The window is effectively
> showing a file:/// URL, and part of the URL no longer exists.

Given that the Finder has a pointer to the file itself, and can look up
the path to that file, it could have been written to update column view
on the fly when things like that change.

But that would not be done, because it would be very confusing for the
user especially since the are in general multiple items in the final
column so the Finder couldn't guess which *one* it was you still want to
be looking at if anything changes, sortathing.

> > Filename extensions are now the only way MacOS X 10.6 works out what to
> > do with a file (boo, hiss).
>
> The file type is still supported,

You get one file type per file extension, so we've really only get
extensions (in effect), surely?

> you can assign individual files to
> specific applications,

Which works only until you do some maintenance or upgrading, then it
breaks. Waste of bloody time, like the old `Comment' field in Finder
info boxes.

> and there are mechanisms based on other metadata
> attached to files (details of which elude me at present). The only
> change in 10.6 in this area is is that the creator code is ignored.
>
> Even that one change is enough for me to agree with you on the "boo,
> hiss" front.

It's broken the MacOS in a lot of ways if you ask me - made my use of my
Mac a *LOT* less convenient. I don't want *.log files to open in bloody
Console just because they're *.log files.

I want *those* *.log files to open in TeXShop, thanks - where they
belong...

Etc., etc.

> > And I'd not be surprised if, by the same token, paths are now
> > significant to this and that. Certainly they are when dealing with some
> > `normal' Unix software ported to Macs that I've used on OS X.
>
> There is a difference in behaviour between Mac-specific aliases (which
> are used in alias files and internally by many applications), and
> text-based pathnames (used in symbolic links, which are common in Unix).

Your reference to `aliases' is confusing - what sort of alias? The sort
of alias we see in the Finder, the *different* sort of alias used by
Applescript, or something else entirely?

> Aliases to files on an HFS or HFS+ volume can track a file or folder as
> it moves around within a volume or it or any parent is renamed, by
> referencing the unique file ID, parent folder ID and other clues. It
> only reverts to behaving like an absolute pathname if the file or a
> parent is deleted.
>
> Symbolic links reference an absolute path and won't follow a file or
> folder which is renamed or moved.

Uhuh.

Ta,
Rowland.

--
Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org
Sorry - the spam got to me
http://www.mag-uk.org http://www.bmf.co.uk
UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
From: David Empson on
Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote:

> David Empson <dempson(a)actrix.gen.nz> wrote:
>
> > Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote:
> >
> > > Tim Streater <timstreater(a)waitrose.com> wrote:
> > >
> > > [snip]
> > >
> > > > I didn't think we did paths in OS X.
> > > [snip]
> > >
> > > I don't know the details of this sort of thing, but:
> > >
> > > Paths and filename extensions used to be more or less irrelevant from
> > > the point of view of the MacOS *before* MacOS X.
> > >
> > > (and if you had an original Mac with the MFS filing system, you actually
> > > had a completely flat filing system - folders weren't directories,
> > > merely a convenience for the user and invisble to the actual filing
> > > system as such. You can look up when HFS appeared as easily as I can, I
> > > suspect...)
> >
> > The Mac OS X Finder has changed the user interface to be based around
> > the concept of a browser,
>
> You wot?
>
> The `concept' is just what it always was, from what I can tell.

No it isn't. Mac OS 9's Finder was entirely based around spatial
principles, remembering the view for each folder, down to the window
position, icon positions, scroll bars, etc. If you open a particular
folder, the window will open in the same place it was most recently
located with the same view you last used.

Mac OS X's Finder has completely broken that concept. Each Finder window
is a file system browser.

You can put it back into something vaguely like Mac OS 9 Finder mode by
clicking on the tool in the top right corner, which hides the toolbar
and sidebar. More recent versions of Mac OS X have progressively broken
more aspects of this, so it is effectively useless if you want Mac OS 9
Finder behaviour.

> I recall quotes from Apple bods say that they couldn't understand why MS
> was moving towards a `browser' type interface for its `Finder-stand-in'.

That must be a pre-Mac OS X quote.

> I don't think you're at all right on this.
>
> > and it supports features like column view
> > (which are explicitly based on absolute paths),
>
> Eh? NThey are based on files, surely? - they show you the path to the
> file.

The columns show the path within the file system, from the starting
point on the left side up to the currently selected folder in the
rightmost column. It is explicitly showing you the path, with one
element of the path per column.

> It's based on the filing system, and the column view is simply a
> convenience for the user which could just have well have been
> implemented with System 7.
>
> Or so it seems to me.
>
> > so it doesn't surprise
> > me if open windows exhibit this behaviour.
>
> Which behaviour do you mean?

The problem described in the original post, where moving a folder causes
another Finder window which was displaying a subfolder to suddenly
revert to showing the generic "computer" view (or a different folder
higher up on the path).

> > The window is effectively
> > showing a file:/// URL, and part of the URL no longer exists.
>
> Given that the Finder has a pointer to the file itself, and can look up
> the path to that file, it could have been written to update column view
> on the fly when things like that change.

But it isn't. Each window is independently showing a particular folder
by pathname, and if the path suddenly stops existing (because you've
moved a parent folder) the window jumps to show a different folder.

> But that would not be done, because it would be very confusing for the
> user especially since the are in general multiple items in the final
> column so the Finder couldn't guess which *one* it was you still want to
> be looking at if anything changes, sortathing.
>
> > > Filename extensions are now the only way MacOS X 10.6 works out what to
> > > do with a file (boo, hiss).
> >
> > The file type is still supported,
>
> You get one file type per file extension, so we've really only get
> extensions (in effect), surely?

No, if you have a file without an extension, but it does have a
traditional Mac OS file type assigned to it, that file type will be used
to select a suitable application to launch.

The extension is higher priority, so the file type is only meaningful if
the filename has no extension.

> > you can assign individual files to specific applications,
>
> Which works only until you do some maintenance or upgrading, then it
> breaks. Waste of bloody time, like the old `Comment' field in Finder
> info boxes.
>
> > and there are mechanisms based on other metadata
> > attached to files (details of which elude me at present). The only
> > change in 10.6 in this area is is that the creator code is ignored.
> >
> > Even that one change is enough for me to agree with you on the "boo,
> > hiss" front.
>
> It's broken the MacOS in a lot of ways if you ask me - made my use of my
> Mac a *LOT* less convenient. I don't want *.log files to open in bloody
> Console just because they're *.log files.
>
> I want *those* *.log files to open in TeXShop, thanks - where they
> belong...
>
> Etc., etc.
>
> > > And I'd not be surprised if, by the same token, paths are now
> > > significant to this and that. Certainly they are when dealing with some
> > > `normal' Unix software ported to Macs that I've used on OS X.
> >
> > There is a difference in behaviour between Mac-specific aliases (which
> > are used in alias files and internally by many applications), and
> > text-based pathnames (used in symbolic links, which are common in Unix).
>
> Your reference to `aliases' is confusing - what sort of alias? The sort
> of alias we see in the Finder, the *different* sort of alias used by
> Applescript, or something else entirely?

They are all more or less the same thing. An alias file as shown by
Finder contains an alias resource, which is what AppleScript is using
(as are most Mac-native applications which keep track of files via
aliases internally).

> > Aliases to files on an HFS or HFS+ volume can track a file or folder as
> > it moves around within a volume or it or any parent is renamed, by
> > referencing the unique file ID, parent folder ID and other clues. It
> > only reverts to behaving like an absolute pathname if the file or a
> > parent is deleted.
> >
> > Symbolic links reference an absolute path and won't follow a file or
> > folder which is renamed or moved.
>
> Uhuh.
>
> Ta,
> Rowland.


--
David Empson
dempson(a)actrix.gen.nz
From: Rowland McDonnell on
David Empson <dempson(a)actrix.gen.nz> wrote:

> Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote:
>
> > David Empson <dempson(a)actrix.gen.nz> wrote:
> >
> > > Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote:
> > >
> > > > Tim Streater <timstreater(a)waitrose.com> wrote:
> > > >
> > > > [snip]
> > > >
> > > > > I didn't think we did paths in OS X.
> > > > [snip]
> > > >
> > > > I don't know the details of this sort of thing, but:
> > > >
> > > > Paths and filename extensions used to be more or less irrelevant from
> > > > the point of view of the MacOS *before* MacOS X.
> > > >
> > > > (and if you had an original Mac with the MFS filing system, you actually
> > > > had a completely flat filing system - folders weren't directories,
> > > > merely a convenience for the user and invisble to the actual filing
> > > > system as such. You can look up when HFS appeared as easily as I can, I
> > > > suspect...)
> > >
> > > The Mac OS X Finder has changed the user interface to be based around
> > > the concept of a browser,
> >
> > You wot?
> >
> > The `concept' is just what it always was, from what I can tell.
>
> No it isn't. Mac OS 9's Finder was entirely based around spatial
> principles, remembering the view for each folder, down to the window
> position, icon positions, scroll bars, etc. If you open a particular
> folder, the window will open in the same place it was most recently
> located with the same view you last used.

And does MacOS X not do that? Okay, I've noticed that views in windows
seem to change when I don't want them to - not quite figured out what's
what yet.

> Mac OS X's Finder has completely broken that concept. Each Finder window
> is a file system browser.

What does that mean?

> You can put it back into something vaguely like Mac OS 9 Finder mode by
> clicking on the tool in the top right corner, which hides the toolbar
> and sidebar. More recent versions of Mac OS X have progressively broken
> more aspects of this, so it is effectively useless if you want Mac OS 9
> Finder behaviour.

<shrug> I dunno.

> > I recall quotes from Apple bods say that they couldn't understand why MS
> > was moving towards a `browser' type interface for its `Finder-stand-in'.
>
> That must be a pre-Mac OS X quote.

Could well have been.

> > I don't think you're at all right on this.
> >
> > > and it supports features like column view
> > > (which are explicitly based on absolute paths),
> >
> > Eh? NThey are based on files, surely? - they show you the path to the
> > file.
>
> The columns show the path within the file system, from the starting
> point on the left side up to the currently selected folder in the
> rightmost column. It is explicitly showing you the path, with one
> element of the path per column.

Erm, yeah - showing you that information, for sure. So?

> > It's based on the filing system, and the column view is simply a
> > convenience for the user which could just have well have been
> > implemented with System 7.
> >
> > Or so it seems to me.
> >
> > > so it doesn't surprise
> > > me if open windows exhibit this behaviour.
> >
> > Which behaviour do you mean?
>
> The problem described in the original post, where moving a folder causes
> another Finder window which was displaying a subfolder to suddenly
> revert to showing the generic "computer" view (or a different folder
> higher up on the path).

Righto.

> > > The window is effectively
> > > showing a file:/// URL, and part of the URL no longer exists.
> >
> > Given that the Finder has a pointer to the file itself, and can look up
> > the path to that file, it could have been written to update column view
> > on the fly when things like that change.
>
> But it isn't.

Seemingly so - but I don't see why it has to be this way, except for
programming convenience.

> Each window is independently showing a particular folder
> by pathname,

Right - now, how do you know that that's what is being done under the
bonnet, so to speak?

> and if the path suddenly stops existing (because you've
> moved a parent folder) the window jumps to show a different folder.

More like `no folder at all, just the top level `computer' place: / in
Unix terms, yes?

> > But that would not be done, because it would be very confusing for the
> > user especially since the are in general multiple items in the final
> > column so the Finder couldn't guess which *one* it was you still want to
> > be looking at if anything changes, sortathing.
> >
> > > > Filename extensions are now the only way MacOS X 10.6 works out what to
> > > > do with a file (boo, hiss).
> > >
> > > The file type is still supported,
> >
> > You get one file type per file extension, so we've really only get
> > extensions (in effect), surely?
>
> No, if you have a file without an extension, but it does have a
> traditional Mac OS file type assigned to it, that file type will be used
> to select a suitable application to launch.

Oh! I didn't know that.

> The extension is higher priority, so the file type is only meaningful if
> the filename has no extension.

Damn. But not totally useless, I suppose. So it's not as bad as I'd
thought.

[snip]

> > > > And I'd not be surprised if, by the same token, paths are now
> > > > significant to this and that. Certainly they are when dealing with some
> > > > `normal' Unix software ported to Macs that I've used on OS X.
> > >
> > > There is a difference in behaviour between Mac-specific aliases (which
> > > are used in alias files and internally by many applications), and
> > > text-based pathnames (used in symbolic links, which are common in Unix).
> >
> > Your reference to `aliases' is confusing - what sort of alias? The sort
> > of alias we see in the Finder, the *different* sort of alias used by
> > Applescript, or something else entirely?
>
> They are all more or less the same thing. An alias file as shown by
> Finder contains an alias resource, which is what AppleScript is using
> (as are most Mac-native applications which keep track of files via
> aliases internally).

Argh. Every explanation I've read of aliases with respect to
Applescript has confused me further, because they've all said something
slightly different. Most have claimed that the aliases inside
Applescript are totally unrelated to Finder aliases. Now I find that's
bollocks, and you've just displayed some information that suddenly makes
things start to make sense.

At bloody last - thank you.

I should have been Jewish, because I need to say `Oi vey' and that's
just wrong if you're not Jewish, innit?

[snip]

Rowland.

--
Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org
Sorry - the spam got to me
http://www.mag-uk.org http://www.bmf.co.uk
UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
 | 
Pages: 1
Prev: Do Vodafone speak English?
Next: Label printing