Resolving aliases would be very helpful!

[SzurszewskiJ]

I see that this has been requested before, and I'd just like to add my vote for PM being able to resolve aliases on OS X.  The rationale for this request is as follows.

I have multiple external drives archiving photos.  It's very common to have a need to generate a set of photos for a specific purpose (say, photos that show winter weather).  These photos live on different drives in a variety of folders.  I start by creating a new folder, and populating that folder with aliases to all photos I think might fit the bill.  I create aliases rather than copying the files primarily for speed.  I would then LIKE to use PM to browse this folder, select the best images, and flag them with star ratings.

Right now, I have to use Bridge CS4 to do this, but it is very slow. 

Would it be fairly straightforward to at least add a preference to resolve file aliases?

[Hayo Baan]

Would it be fairly straightforward to at least add a preference to resolve file aliases?

I would say directory aliases are as at least as important in this respect (if not more so).
Please note, however, there are three types of "aliases" on the Mac.
1. An alias as created with the Mac GUI.
2. A soft link (e.g., as created with the Terminal command ln -s).
3. A hard link (e.g., as created with the Terminal command ln -s).

The hard link is actually already supported as it looks like a normal file. Support for the other two would be very very much appreciated as this would enable, for instance, a single directory structure for all your image files even when this is split across different media.

I don't know how hard it would be to implement "aliases" within PM though, and this may in fact be quite a big one...

Cheers,
    Hayo

[Kirk Baker]

Hayo,

Would it be fairly straightforward to at least add a preference to resolve file aliases?

I would say directory aliases are as at least as important in this respect (if not more so).
Please note, however, there are three types of "aliases" on the Mac.
1. An alias as created with the Mac GUI.
2. A soft link (e.g., as created with the Terminal command ln -s).
3. A hard link (e.g., as created with the Terminal command ln -s).

The hard link is actually already supported as it looks like a normal file. Support for the other two would be very very much appreciated as this would enable, for instance, a single directory structure for all your image files even when this is split across different media.

I don't know how hard it would be to implement "aliases" within PM though, and this may in fact be quite a big one...

The issue is that PM often accesses files on multiple simultaneous threads and some aliases need to interact with the user in order to be resolved.  This cannot be done on background threads.  Well, flags can be passed in that specify that no UI should be presented, but that may mean that the alias won't be resolved anyway and then the file cannot be accessed.

-Kirk

[Hayo Baan]

The issue is that PM often accesses files on multiple simultaneous threads and some aliases need to interact with the user in order to be resolved.  This cannot be done on background threads.  Well, flags can be passed in that specify that no UI should be presented, but that may mean that the alias won't be resolved anyway and then the file cannot be accessed.

Why would aliases resolving require input  from the user? I would say that if the aliased file can't be accessed, then a "proxy" icon could be shown indicating the file is actually an alias (and has problem resolving).

I can see this all would trigger quite some additional code (all file access probably needs rewriting to perform the alias resolution) and you already have ample on your plate …

Cheers,
    Hayo

[Kirk Baker]

Hayo,

The issue is that PM often accesses files on multiple simultaneous threads and some aliases need to interact with the user in order to be resolved.  This cannot be done on background threads.  Well, flags can be passed in that specify that no UI should be presented, but that may mean that the alias won't be resolved anyway and then the file cannot be accessed.

Why would aliases resolving require input  from the user? I would say that if the aliased file can't be accessed, then a "proxy" icon could be shown indicating the file is actually an alias (and has problem resolving).

I can see this all would trigger quite some additional code (all file access probably needs rewriting to perform the alias resolution) and you already have ample on your plate …

The resolution of aliases can prompt a user to log onto a server for instance.  That cannot be performed on a background thread.

There are many issues that arise when allowing aliases to work in an application such as Photo Mechanic.  For instance renaming.  If the user wants to rename the file, does the alias itself get renamed, or does the actual file get renamed?  If the file pointed to gets renamed then the alias needs to be updated.  Or do both the alias and the actual file get renamed?  What if an 'Arrangement' had been made in the location where the actual file resides and we decide that renaming affects the actual file?  The Arrangement would no longer be valid the next time you browse the folder where the actual file resides.  Photo Mechanic would need to check to see if an Arrangement file existed in the actual file's location and patch it up.  Or if a multi-folder Favorite was referencing those files it would also have to be patched.

Another issue (these are just coming to mind right now and I am sure there are other implications) would be, what if the alias and the file being pointed to didn't have the same name?  What should be shown in the contact sheet as the file name?  The aliases name?  The actual file's name?  When evaluating variables such as {filename}, {filenamebase}, and {path} what should be their value?  When you select a photo and its path is shown at the bottom of the contact sheet, what path should be shown?

I can see that there would be a lot of issues. Some would be solved easily by making a decision about which file/alias had the higher priority, and others would be very tedious to solve.

-Kirk

[Hayo Baan]

Kirk,

The resolution of aliases can prompt a user to log onto a server for instance.  That cannot be performed on a background thread.

I actually thought of that one already, and yeah, this could be problematic.

There are many issues that arise when allowing aliases to work in an application such as Photo Mechanic.  For instance renaming.  If the user wants to rename the file, does the alias itself get renamed, or does the actual file get renamed?  If the file pointed to gets renamed then the alias needs to be updated.  Or do both the alias and the actual file get renamed?  What if an 'Arrangement' had been made in the location where the actual file resides and we decide that renaming affects the actual file?  The Arrangement would no longer be valid the next time you browse the folder where the actual file resides.  Photo Mechanic would need to check to see if an Arrangement file existed in the actual file's location and patch it up.  Or if a multi-folder Favorite was referencing those files it would also have to be patched.

Another issue (these are just coming to mind right now and I am sure there are other implications) would be, what if the alias and the file being pointed to didn't have the same name?  What should be shown in the contact sheet as the file name?  The aliases name?  The actual file's name?  When evaluating variables such as {filename}, {filenamebase}, and {path} what should be their value?  When you select a photo and its path is shown at the bottom of the contact sheet, what path should be shown?

I can see that there would be a lot of issues. Some would be solved easily by making a decision about which file/alias had the higher priority, and others would be very tedious to solve.

Wow, you're absolutely right; resolving aliases could indeed cause lots of potential problems, all of which the user would expect PM to take care of/prevent... Simply (imo) too much bother to even try.

Hmm, but how about aliases to complete folders then, would this be doable? It wouldn't give any of the problems above, would it?
The only thing that might be different between (files in) the actual folder or the aliased folder would potentially be the {folder} and {folderpath} variables, but I guess these could even be forced to their "real" value.

Cheers, and thanks for even thinking about all this