Hmm. So the alias file is really called "numbers files f alias" exactly? You don't have any funky FinderPop "---x" suffixes?
And the alias really does work?
Does the alias show up expanded when you right-click a file in the Finder? (The menubar popups are handled by the FinderPop daemon which starts early and builds its menus early too...) Could it be that the disk it's on wasn't mounted at the time FinderPop built its menus?
An easy way to check this would be to force FP to rebuild it's menus. Either go to the prefPane and turn FP off and then back on, or open up the FinderPop Items folder and create a new folder there, and then immediately delete it (Command-Shift-N, Command-Delete) - this will cause the modification time of the FinderPop Items folder to be changed, and FP will rebuild its menus for the folder the next time it's invoked.
FP will print something to the Console (Applications -> Utiltities->Console.app) if it finds something funky while scanning files. (But an unfollowable alias isn't considered 'funky' IIRC.)
24 Jun 2010, 21:13
This is a rather recent problem, perhaps a couple of months.
I have many folder aliases in my FinderPop Menu items list. All except one reliably expand to show their contents when selected. I use mostly a click in unused menu bar feature.
But one folder - numbers files alias - is reported in italics and does NOT show its contents even when the removable disk (BDI) it's on is mounted. Expansion used to work reliably, but not for a while now. Sometimes it's in regular type and does expand, but not very often. I haven't been able to see any pattern to when FinderPop expands it and when it doesn't.
I've just moved to 10.6.4, but that has not solved the problem
How can I help debug you this problem?
- Attachments
-
- This png shows the folder actually open, yet FinderPop lists its name (selected) in italics which suggests it doesn't realize this folder is available
- FinderPop declines to expand a folder even though it is available.png (39.34 KiB) Viewed 4414 times
- CrisBCT
- Posts: 18
- Joined: 03 Dec 2009, 10:25
Re: FP doesn't expand folder although it's there
by turly » 25 Jun 2010, 07:52
25 Jun 2010, 11:04
Yes, it's really called "numbers files f alias" exactly. No suffixes. And I clicked on it to open the folder as shown in the png I attached.
The folder is called "numbers files ƒ" exactly. And the alias in FP items file does work. Furthermore, if the BDI is not up, then it asks for the password and then loads it which is exactly what I want.
When I right click a file in the Finder, and right click in an unused area on the desktop, it shows expanded for both.
I went to the Prefpane, turned FP off and then back on. And now it does show expanded when I click in unused menu bar.
I would imagine FP builds its menus when the Mac is booted, which suggests that it would never have this folder up to start with since it's on a removable disk (BDI) which is only mounted later when I need it.
But this used to work most all the time, I believe. And since my BDI usually stays loaded, shouldn't it have had the same issue back then?
Now I'm left wondering how come it used to work, and why this problem is surfacing now...
fyi, sometimes I go to a regular file in the FP items menu, and nothing happens, it just doesn't load as it should. So, on reflection, this might be a related problem.. But since regular files are not on the BDI, and don't show in italics, perhaps it's different?
26 Jun 2010, 16:18
I've just rebooted, and used the FinderPop unused menu bar drop-down to mount the BDI containing this folder from the numbers files ƒ alias. But even though it's just gone the the load process for me, FinderPop continues to show it in italics and not expand it.
But when I navigate to it via the Desktop expanded menu, then it is NOT in italics and I can get to its contents. See
FP does sees it via the Desktop expanded dropdown.png
- FP does sees it via the Desktop expanded dropdown.png (91.11 KiB) Viewed 4395 times
In this png you can see it in italics at the top with no expansion, and also at the bottom left without italics and with expansion arrowhead...
19 Jul 2010, 15:55
Hi Turly,
That recent crash may be associated with this already reported problem. Here are two pngs taken at the same time.
The earlier png shows a menu bar click with the numbers folder name in italics and so not expanded. See:
Screen shot 2010-07-19 at 16.37.08.png
The later png, an option click on the desktop, shows the same numbers folder expanded...
Screen shot 2010-07-19 at 16.38.06.png
Which, I believe, suggests there's probably something wrong somewhere. Shouldn't they both show the same - no matter where the click is made?
- Attachments
-
- same numbers folder name NOT in italics, and it expands
- Screen shot 2010-07-19 at 16.38.06.png (137.43 KiB) Viewed 4366 times
-
- numbers folder name in italics not expandable
- Screen shot 2010-07-19 at 16.37.08.png (50.2 KiB) Viewed 4366 times
- CrisBCT
- Posts: 18
- Joined: 03 Dec 2009, 10:25
Re: FP doesn't expand folder although it's there
by turly » 19 Jul 2010, 19:34
The menubar click popup menu is in an entirely separate application to the click-on-the-desktop - the former is in the FinderPop Daemon, and the latter is in the Finder. Both of them have separate caches.
FP's caches work on a folder's modification time. When asked to display a menu corresponding to a particular folder, FinderPop looks to see if it already has one and that the folder modification date is the same as when the menu was built.
So say we have no menus built and that your FinderPop Items folder contains a single alias... and at the time of making the menu, FinderPop finds that the alias is not resolvable, so it adds the alias to the menu in italics. If the alias is resolvable, then everything works as normal.
The daemon runs at startup and so may have cached the menu when the alias was not resolvable. The Finder runs a bit later and the menu may only be built when you control-click, at which time your item has become available.
Note that the fact that the item referred to by the alias becomes available at some later point in time does not change the modification date of the folder containing the original alias (and so I have no way of knowing that I should rebuild that menu.)
It may be feasible to solve this as follows: if, when building a menu, I come across an unresolvable alias, I mark the menu as being valid only for this invocation of FinderPop. I.e., the next time FinderPop is invoked and wants to display that menu again, it is rebuilt from scratch. This might have bad repercussions if people have lots of unresolvable aliases, some of which never become available - this will cause FP to rebuild the correponding menu from scratch if it is required on following invocations of FinderPop...
By way of a workaround, turning FinderPop off and on in the prefPane will cause all menus to be rebuilt next time...
FP's caches work on a folder's modification time. When asked to display a menu corresponding to a particular folder, FinderPop looks to see if it already has one and that the folder modification date is the same as when the menu was built.
So say we have no menus built and that your FinderPop Items folder contains a single alias... and at the time of making the menu, FinderPop finds that the alias is not resolvable, so it adds the alias to the menu in italics. If the alias is resolvable, then everything works as normal.
The daemon runs at startup and so may have cached the menu when the alias was not resolvable. The Finder runs a bit later and the menu may only be built when you control-click, at which time your item has become available.
Note that the fact that the item referred to by the alias becomes available at some later point in time does not change the modification date of the folder containing the original alias (and so I have no way of knowing that I should rebuild that menu.)
It may be feasible to solve this as follows: if, when building a menu, I come across an unresolvable alias, I mark the menu as being valid only for this invocation of FinderPop. I.e., the next time FinderPop is invoked and wants to display that menu again, it is rebuilt from scratch. This might have bad repercussions if people have lots of unresolvable aliases, some of which never become available - this will cause FP to rebuild the correponding menu from scratch if it is required on following invocations of FinderPop...
By way of a workaround, turning FinderPop off and on in the prefPane will cause all menus to be rebuilt next time...
01 Oct 2010, 20:45
Hi Turly,
Yes, this makes a lot of sense.
Rebuilding a menu when there's an unresolved alias could indeed be a problem for some people. A simple solution could be to create an Option for this. Check to rebuild menus with unresolved aliases, uncheck to continue as currently...
Hope you're enjoying your summer and autumn...