Path Finder 4 comments

In Matt's otherwise excellent article under this title, he asks:

When you drag multiple files into a folder, and the Finder asks if you want to replace an existing file, why doesn't it report relative modification dates? When you drag one file into a folder, the Finder tells you whether an existing file with the same name is older or newer. But if you drag multiple files into a folder, it doesn't - it puts up a separate dialog for each existing file, asking whether you want to replace it, but without the relative date information, which is usually crucial to making an intelligent decision about whether to proceed.

Unfortunately, since OS X took center stage the modification date on files and folders has become untrustworthy. Under MacOS 7/8/9, it applied just to the file content; you could change file type and creater (for example) without affecting the modification date. Now, however, it also applies to at least some (but not all!) of the file's metadata. For example, if you change the default opener program for a file, the modification timestamp changes. On the other hand, if you change the permissions for a file, the timestamp doesn't change.

What's at least as bad is that if you open a folder to see what's in it, the timestamp on the containing folder changes!

I looked for info about this situation on apple.com, but didn't find any mention of it. I don't know whether it came from the *nix/BSD roots of OS X or was a decision by Apple's developers, but it's deplorable, IMHO. There's no way to know whether a difference in modification dates was caused by a change in content or a change in metadata, so it's quite possible for a file to have a newer modification date while the the content is actually older.

So if you plan to buy Path Finder for your Tiger system (as I do), remember NOT to make decisions based on timestamps! (The new Path Finder 4 does NOT run on Panther, though. If you're still running that, you'll have to be content with an unsupported older version.)

Carl

P.S. I did find mention that it is possible and legitimate under newer filesystems to have a file creation date that is more recent than the file's modification date. Go figure!

Matt,

You compare tab creation to Safari's feature: "Tabs aren't as easily created as in Safari by Command-double-clicking."

In Safari, it's even easier than this, no: Command-single click.

-John Crosby

Carl S Zimmerman wrote:

>(The new Path Finder 4 does NOT run on Panther, though. If you're
>still running that, you'll have to be content with an unsupported
>older version.)

But amusingly (rapidly becoming irritating, as there's no way to turn
off automatic checking for updates), even if you're running Panther,
PathFinder v.3 still prompts you to upgrade to v.4...


And, talking of holding back on upgrading PathFinder even though we
love it dearly, I'm still running v.3.1 because its USP was
implementing file labels like OS 9 used to do, i.e. colourising the
_whole_ icon.

But then, as I work exclusively in list view with 16x16 icons, the
small blob of colour implemented in v.3.2 hardly shows up at that
size on Photoshop icons, for example.

I complained bitterly to Cocoatech at the time, but judging from the
support forum for PF V.4 it looks like they've broken labels even
more!

http://www.cocoatech.com/forum/viewtopic.php?t=1079

I'd run with Labels X but it's a haxie.

http://www.unsanity.com/haxies/labels


--
Chris Reed, BBR Solutions Ltd * http://www.bbr-online.com

>You compare tab creation to Safari's feature: "Tabs aren't as easily
>created as in Safari by Command-double-clicking."
>
>In Safari, it's even easier than this, no: Command-single click.

This was my addition; I know that it requires only a single-click in
Safari, but my intent in saying Command-double-click is that it would
make no sense in Path Finder to take cover Command-single-click for
opening in a new tab, given that Command-clicking in Path Finder
should be a discontiguous select.

cheers... -Adam

--
New Take Control ebooks! ........... http://www.takecontrolbooks.com/
_____________________________________________________________________
Adam C. Engst: I publish TidBITS, write books, and make sure the
acetidbits.com right people know each other in the Mac industry.
Me: http://www.tidbits.com/adam/ TidBITS: http://www.tidbits.com/

I'm a big fan of PathFinder as well. It has pretty much replaced the
Finder for most tasks, which leads to its own set of frustrations,
mostly having to do with the Finder being hard wired in to OSX as the
default file management environment.

- PathFinder is set to launch at log in and to quit the Finder when
it does. But a lot of things---like inserting a disk or mounting a
volume causes the Finder to relaunch. And since I'm using the
PathFinder desktop, when the Finder launches underneath PathFinder, I
get double icons showing up on the desktops which is rather annoying.

- Similarly, the trash can in the dock seems to be hard wired to the
Finder, so becomes non-operational when the Finder isn't running.

These are some of the many annoyances that arises from Finder being
hard wired into OSX. But I suppose Cocoatech can't do much about that.

One real annoyance that Cocoatech can do something about is to allow
authentication on a single transaction. For example, when a user
without admin privileges tries to move something into the
Applications folder, the Finder will allow the user to authenticate
as an admin user for that one transaction only. PathFinder not only
doesn't allow that, it also gives you no feedback. It simply does
not perform the task. I suppose you can launch PathFinder itself
with root privileges, but given the amount of damage that might be
done that seems like a really bad idea.

Tomoharu Nishino

On Feb 7, 2006, at 11:29 PM, A. Lee Bennett Jr. wrote:

> Why did the option to disable the Empty Trash warning that we had
> in version 3 (can't say about version 1 or 2 since I never used those)
> disappear?

I whole heartedly agree with all your other points. But this one is
still there but buried in the "General" preferences.

Tomoharu Nishino

On 10/2/2006 4:20 AM, "Adam C. Engst" <acetidbits.com> spake thus:

> Command-clicking in Path Finder should be a discontiguous select

Unless you click on the "open button" in list view. I could see
command-click on that as a legitimate "open in new tab" option (but only for
folders, of course). Interestingly enough, command-click on the open button
currently opens the folder in a new window. This begs for a configurable
option...

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

On 2006-02-08, at 18:19, Carl S Zimmerman wrote:

> Under MacOS 7/8/9, it
> applied just to the file content; you could change file type and
> creater (for example) without affecting the modification date. Now,
> however, it also applies to at least some (but not all!) of the
> file's metadata. For example, if you change the default opener
> program for a file, the modification timestamp changes.

Your example should be the only metadata action which updates the
modification date of a file. It's because OS X adds a resource fork
when you override the default opener.

On 2/10/06 at 5:11 AM, cheshirenekomac.com wrote:

>I'm a big fan of PathFinder as well. It has pretty much replaced
>the Finder for most tasks, which leads to its own set of
>frustrations, mostly having to do with the Finder being hard wired
>in to OSX as the default file management environment.

>- PathFinder is set to launch at log in and to quit the Finder when
>it does. But a lot of things---like inserting a disk or mounting a
>volume causes the Finder to relaunch. And since I'm using the
>PathFinder desktop, when the Finder launches underneath PathFinder,
>I get double icons showing up on the desktops which is rather
>annoying.

>- Similarly, the trash can in the dock seems to be hard wired to
>the Finder, so becomes non-operational when the Finder isn't
>running.

There are a couple of hacks that go almost eliminate all of these issues and allow Path Finder to more completely replace the Finder

Open the login window plist file, com.loginwindow.plist, with the Property List Editor (part of the developer tools) or another plist editor of your choice. Find the Finder item. That will be a string with the path to Finder. Replace that string with the path to PathFinder.

Open the Path Finder package to edit the file Contents/Pkginfo with any available text editor. That file consists of a single string in all caps. Replace it with FNDRMACS.

Once you've done both of these, you will no longer need to have the launch Path Finder automatically after log-in enabled or the Quit the Finder automatically at launch enabled in Path Finder's general preferences. The first hack causes the login window process to replace the Finder with Path Finder making these preferences unnecessary. The second hack causes the system to re-direct things normally directed to the Finder to Path Finder such as AppleEvents.

The login window hack has no impact on the way other applications run. But the second hack may cause some applications to fail. If an application sends out an AppleEvent Path Finder cannot deal with then there will be a problem. I've not seen any difficulty with major apps but I have seen a couple of minor apps have this problem. Thus far, I've not found this problem in any app I consider essential, i.e., those apps that had difficulty playing nice with Path Finder and this hack have been simply eliminated from my hard drive.

There is one other hack that doesn't do much except for appearances that reduces the dominance of the Finder. That making the Finder's dock icon removable from the Dock. This can be done with Transparent Dock, a shareware app available at the usual places.

On 11/2/2006 2:11 AM, "cheshirenekomac.com" <cheshirenekomac.com> spake
thus:

> And since I'm using the
> PathFinder desktop, when the Finder launches underneath PathFinder, I
> get double icons showing up on the desktops which is rather annoying.

That's weird, I don't get this. OK, normally I don't bother quitting the
Finder at all (I decided it wasn't worth the effort in general given that it
tends to come back at some stage anyway, plus I use the Dock Trash icon most
of the time), but I just now tried quitting and relaunching it and still
didn't get this effect. The only way this could happen is if the Finder's
desktop window ended up in front of Path Finder's. A quick fix might be to
hide then show Path Finder's desktop, but given the hassle of that it would
probably be easier to just leave the Finder running but hidden.

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

On 11/2/2006 2:11 AM, "cheshirenekomac.com" <cheshirenekomac.com> spake
thus:

> But a lot of things---like inserting a disk or mounting a
> volume causes the Finder to relaunch.

OK, I also definitely DON'T get this effect. With the Finder not running, I
just mounted a network volume and inserted a CD. The Finder didn't launch
for either of them. Two questions:

Do you have the most recent Path Finder?

Could there be some other preference in the system (not Path Finder) that
causes this effect?

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

On Feb 13, 2006, at 1:07 AM, Nigel Stanger wrote:

> On 11/2/2006 2:11 AM, "cheshirenekomac.com" <cheshirenekomac.com>
> spake
> thus:
>
>> But a lot of things---like inserting a disk or mounting a
>> volume causes the Finder to relaunch.
>
> OK, I also definitely DON'T get this effect. With the Finder not
> running, I
> just mounted a network volume and inserted a CD. The Finder didn't
> launch
> for either of them. Two questions:
>
> Do you have the most recent Path Finder?
>
> Could there be some other preference in the system (not Path
> Finder) that
> causes this effect?

Okay, after reading your post, I tried a few things to no avail.

Then I trashed all the Path Finder preferences. And both problems
(the auto-launching the Finder as well as the Finder desktop showing
up "under" the PF desktop) went away. Go figure. I had tried an
older version of PF more than a year ago. So perhaps the older Prefs
were somehow mucking things up?

Tomoharu

On 14/2/2006 5:03 AM, "cheshirenekomac.com" <cheshirenekomac.com> spake
thus:

> So perhaps the older Prefs were somehow mucking things up?

That's entirely possible. Preferences corruption and/or confusion can cause
all sorts of weird problems. It can be occasionally useful to just throw
away the prefs for an app and start again from scratch (especially if you've
been through several major upgrades).

I still find it amazing that no-one has come up with a good solution for
smoothly migrating prefs between different versions of the same app (or even
different apps). XML property lists *should* be a great solution, but yet we
still get weird stuff like this happening.

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

On 8/02/2006, at 6:19 PM, Carl S Zimmerman wrote:

> What's at least as bad is that if you open a folder to see what's in
> it, the timestamp on the containing folder changes!

This factor, alone, makes the time stamp a total wast of time for me.

Just lately, I have had computer problems that have caused me to
startup and operate for varying times on a number of clones from my
computers internal HD. Syncing the various folders is eventually
going to become a nightmare. It would be acceptable if there were two
separate dates, a last viewed and a last modified date. However as it
stands it makes a mockery of the information. Just imagine if every
time a copy of a newspaper was read the edition date changed!

-Neil

I have a question for Bill Rowe, who wrote:

Open the login window plist file, com.loginwindow.plist, with the Property List Editor (part of the developer tools) or another plist editor of your choice. Find the Finder item. That will be a string with the path to Finder. Replace that string with the path to PathFinder.

I can't find this file. I have no file named "com.loginwindow.plist" and "com.apple.loginwindow.plist" does not seem to have a path to Finder. I've looked in ~/Library, /Library, and even /System/Library. What am I missing?

Thanks, Kate

On 2/14/06 at 3:13 PM, katederiemac.com (Kate Derie) wrote:

>I have a question for Bill Rowe, who wrote:

>Open the login window plist file, com.loginwindow.plist, with the
>Property List Editor (part of the developer tools) or another plist
>editor of your choice. Find the Finder item. That will be a string
>with the path to Finder. Replace that string with the path to
>PathFinder.

>I can't find this file. I have no file named
>"com.loginwindow.plist" and "com.apple.loginwindow.plist" does not
>seem to have a path to Finder. I've looked in ~/Library, /Library,
>and even /System/Library. What am I missing?

On my system I see the file com.apple.loginwindow.plist in ~/Library/Preferences. When I open it with the Property List Editor (installed from the developer portion of the system installer) I see 4 items after clicking on the root arrow. The first item is titled Finder with a string value having the path to the Finder that I changed to be the path to Path Finder.

Although, I am currently running Tiger (10.4.5) it is possible this file is left over from either Panther or Jaguar and no longer used. I seem to remember that it used to have a list of the various items that you set to launch on login. When I just looked at this file, I saw that was not currently the case on my system. And it is this that makes me suspect this may be a hold over from a prior system install.

Perhaps someone else can add some comments?

I'm running 10.4.4 on a fresh install of 10.4. I have no com.apple.loginwindow.plist in ~/Library/Preferences. A search for "login" finds three likely files that have been modified in the last month:

/Library/Preferences/com.apple.loginwindow.plist

~/Library/Preferences/loginwindow.plist

/System/Library/CoreServices/loginwindow.app

I don't have Developer Tools installed, so can't look at these, but maybe one of them is the file you're looking for.

On 2006-02-17, at 05:08, handymac wrote:

> ~/Library/Preferences/loginwindow.plist
> [...]
> I don't have Developer Tools installed, so can't look at these

Sure you can:

defaults read loginwindow

(note the domain (last argument) is just the plist filename without
the extension)