Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #69575 > unrolled thread

Alias Strangeness on Shared Volumes

Back to article view | Back to comp.sys.mac.system

Contents

  Alias Strangeness on Shared Volumes Nelson <nelson@nowhere.com> - 2015-02-07 17:55 -0500
    Re: Alias Strangeness on Shared Volumes Jolly Roger <jollyroger@pobox.com> - 2015-02-07 23:03 +0000
    Re: Alias Strangeness on Shared Volumes FPP <fredp151@gmail.com> - 2015-02-08 06:07 -0500
      Re: Alias Strangeness on Shared Volumes android <here@there.was> - 2015-02-08 12:17 +0100
      Re: Alias Strangeness on Shared Volumes Nelson <nelson@nowhere.com> - 2015-02-08 07:17 -0500
    Re: Alias Strangeness on Shared Volumes Jolly Roger <jollyroger@pobox.com> - 2015-02-08 13:36 +0000
    Re: Alias Strangeness on Shared Volumes Nelson <nelson@nowhere.com> - 2015-02-08 08:52 -0500
      Re: Alias Strangeness on Shared Volumes Jolly Roger <jollyroger@pobox.com> - 2015-02-08 14:55 +0000
        Re: Alias Strangeness on Shared Volumes Jolly Roger <jollyroger@pobox.com> - 2015-02-08 15:14 +0000
          Re: Alias Strangeness on Shared Volumes Nelson <nelson@nowhere.com> - 2015-02-08 18:28 -0500
            Re: Alias Strangeness on Shared Volumes Jolly Roger <jollyroger@pobox.com> - 2015-02-08 23:50 +0000
        Re: Alias Strangeness on Shared Volumes Nelson <nelson@nowhere.com> - 2015-02-08 13:09 -0500

#69575 — Alias Strangeness on Shared Volumes

Two Macs, A and B, and an external drive, D, connected to B via USB and 
shared over the network.

Alias files on B or D resolve correctly when accessed from B.  However 
when B and/or D are mounted on A as shared volumes over the network, 
and the same alias files are accessed from A, I get the message "... 
Original can't be found.  Fix alias?".  And with some of them (but not 
all), the "can't be found" message is preceded by a "Connection failed" 
message.

Finally, if I make an alias on B or D from A, it resolves correctly on 
both machines.

Is this a "feature" of OS X?  Any ideas what is causing it and how to 
fix it?

-- 
Nelson

[toc] | [next] | [standalone]

#69576

On 2015-02-07, Nelson <nelson@nowhere.com> wrote:
> Two Macs, A and B, and an external drive, D, connected to B via USB and 
> shared over the network.
>
> Alias files on B or D resolve correctly when accessed from B.  However 
> when B and/or D are mounted on A as shared volumes over the network, 
> and the same alias files are accessed from A, I get the message "... 
> Original can't be found.  Fix alias?".  And with some of them (but not 
> all), the "can't be found" message is preceded by a "Connection failed" 
> message.
>
> Finally, if I make an alias on B or D from A, it resolves correctly on 
> both machines.
>
> Is this a "feature" of OS X?  Any ideas what is causing it and how to 
> fix it?

More likely a bug.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#69578

On 2015-02-07 22:55:32 +0000, Nelson <nelson@nowhere.com> said:

> Two Macs, A and B, and an external drive, D, connected to B via USB and
> shared over the network.
> 
> Alias files on B or D resolve correctly when accessed from B.  However
> when B and/or D are mounted on A as shared volumes over the network,
> and the same alias files are accessed from A, I get the message "...
> Original can't be found.  Fix alias?".  And with some of them (but not
> all), the "can't be found" message is preceded by a "Connection failed"
> message.
> 
> Finally, if I make an alias on B or D from A, it resolves correctly on
> both machines.
> 
> Is this a "feature" of OS X?  Any ideas what is causing it and how to
> fix it?

I think we may have gone over this before... are you using Yosemite?

Yosemite treats alias' differently than previously.  I found that using 
symbolic links works where the usual alias' didn't.

http://www.experchange.com/yosemite-alias-problems-and-workaround-t4397583
-- 
Q: How do you know when <NoBody@nowhere.com> is lying?  A: Ubiquitous 
<weberm@polaris.net> fingers are moving.
<NoBody@nowhere.com> reveals himself to be a sockpuppet of sickpuppy 
Ubiquitous <weberm@polaris.net>
http://al.howardknight.net/msgid.cgi?STYPE=msgid&A=0&MSGI=%3Cm3jcte%24pq1%241%40dont-email.me%3E 

[toc] | [prev] | [next] | [standalone]

#69580

In article <mb7g0u$4ft$1@dont-email.me>, FPP <fredp151@gmail.com> 
wrote:

> On 2015-02-07 22:55:32 +0000, Nelson <nelson@nowhere.com> said:
> 
> > Two Macs, A and B, and an external drive, D, connected to B via USB and
> > shared over the network.
> > 
> > Alias files on B or D resolve correctly when accessed from B.  However
> > when B and/or D are mounted on A as shared volumes over the network,
> > and the same alias files are accessed from A, I get the message "...
> > Original can't be found.  Fix alias?".  And with some of them (but not
> > all), the "can't be found" message is preceded by a "Connection failed"
> > message.
> > 
> > Finally, if I make an alias on B or D from A, it resolves correctly on
> > both machines.
> > 
> > Is this a "feature" of OS X?  Any ideas what is causing it and how to
> > fix it?
> 
> I think we may have gone over this before... are you using Yosemite?
> 
> Yosemite treats alias' differently than previously.  I found that using 
> symbolic links works where the usual alias' didn't.
> 
> http://www.experchange.com/yosemite-alias-problems-and-workaround-t4397583

OSX is kill joy with aliases. One used to be able to shorten the path of 
a file a link. Now for no good reason what so ever it resolves it!
-- 
teleportation kills

[toc] | [prev] | [next] | [standalone]

#69581

On Sun, 8 Feb 2015 06:07:46 -0500, FPP wrote
(in article <mb7g0u$4ft$1@dont-email.me>):

[snip]
> I think we may have gone over this before... are you using Yosemite?

Snow Leopard.  I have seen this problem many times before over the last 
couple of years but was always too busy doing something else to 
investigate and just worked around it.  Lately I need to work on data 
on a shared drive and it is becoming a royal pain in the ass.


-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#69582

On 2015-02-07, Nelson <nelson@nowhere.com> wrote:
> Two Macs, A and B, and an external drive, D, connected to B via USB and 
> shared over the network.
>
> Alias files on B or D resolve correctly when accessed from B.  However 
> when B and/or D are mounted on A as shared volumes over the network, 
> and the same alias files are accessed from A, I get the message "... 
> Original can't be found.  Fix alias?".  And with some of them (but not 
> all), the "can't be found" message is preceded by a "Connection failed" 
> message.
>
> Finally, if I make an alias on B or D from A, it resolves correctly on 
> both machines.
>
> Is this a "feature" of OS X?  Any ideas what is causing it and how to 
> fix it?

Take a look at the aliases that are not working, and check to see what
the owner, group, and permissions settings are for the *destination*
file or folder. Is it possible the user account with which you connect
to this shared volume does not have permission to access the destination
file or folder for the alias? 

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#69583

On Sat, 7 Feb 2015 17:55:32 -0500, Nelson wrote
(in article <0001HW.D0FC02140001F0ECB01029BF@news.astraweb.com>):

> Two Macs, A and B, and an external drive, D, connected to B via USB and 
> shared over the network.
> 
> Alias files on B or D resolve correctly when accessed from B.  However 
> when B and/or D are mounted on A as shared volumes over the network, 
> and the same alias files are accessed from A, I get the message "... 
> Original can't be found.  Fix alias?".  And with some of them (but not 
> all), the "can't be found" message is preceded by a "Connection failed" 
> message.
> 
> Finally, if I make an alias on B or D from A, it resolves correctly on 
> both machines.
> 
> Is this a "feature" of OS X?  Any ideas what is causing it and how to 
> fix it?

Followup:  It looks like the problem, or at least part of the problem,  
is Carbon Copy Cloner.  Turns out drive D is a clone of drive C.  When 
I mount C, the alias on D resolves to the original on on C, _not_ the 
original on D.  If C is not mounted, the alias fails to resolve, which 
probably explains the "Connection Failed" message.

Well, that sucks.  I use CCC to back up all my external drives and make 
extensive use of aliases to, for example, categorize things without 
actually moving them into category folders (allows an item to appear in 
multiple categories).

To make things worse, C is a subsequent generation clone from an 
earlier, smaller drive so there are aliases that won't resolve on 
either.

For some reason these problems only appear when the the drive is 
accessed over the network.  When it is directly connected, the aliases 
in question resolve.  So it can't be all CCC's fault.

I wonder if there is a utility to straighten all this out.  If not, 
I'll probably try to write an Applescript to find all aliases and 
re-point them to the current drive.

-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#69584

On 2015-02-08, Nelson <nelson@nowhere.com> wrote:
>
> Followup:  It looks like the problem, or at least part of the problem,  
> is Carbon Copy Cloner.  Turns out drive D is a clone of drive C.  When 
> I mount C, the alias on D resolves to the original on on C, _not_ the 
> original on D. 

Aha. You hadn't mentioned this in your original post. The alias to a
file/folder on C will always resolve to C because the original *is* on
C. So it's operating as designed.

> If C is not mounted, the alias fails to resolve, which 
> probably explains the "Connection Failed" message.

That's the behavior one would expect, though. C is a different volume
from D, despite having a duplicate set of contents. And aliases always
point to the *original* item.

> Well, that sucks.  I use CCC to back up all my external drives and make 
> extensive use of aliases to, for example, categorize things without 
> actually moving them into category folders (allows an item to appear in 
> multiple categories).
>
> To make things worse, C is a subsequent generation clone from an 
> earlier, smaller drive so there are aliases that won't resolve on 
> either.
>
> For some reason these problems only appear when the the drive is 
> accessed over the network.  When it is directly connected, the aliases 
> in question resolve.  So it can't be all CCC's fault.

You're saying an alias to a file on C will resolve to a file on D when D
is physically mounted, but not when D is mounted over the network? Are
you sure about that? Hmmm...

> I wonder if there is a utility to straighten all this out.  If not, 
> I'll probably try to write an Applescript to find all aliases and 
> re-point them to the current drive.

That sounds like the correct solution to the problem since the aliases
are still pointing to items on the other original volume(s). 

I actually wrote exactly such a script a while back. Enjoy:

<http://jollyroger.kicks-ass.org/software/Resolve%20Aliases.zip>

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#69585

On 2015-02-08, Jolly Roger <jollyroger@pobox.com> wrote:
>
>> I wonder if there is a utility to straighten all this out.  If not, 
>> I'll probably try to write an Applescript to find all aliases and 
>> re-point them to the current drive.
>
> That sounds like the correct solution to the problem since the aliases
> are still pointing to items on the other original volume(s). 
>
> I actually wrote exactly such a script a while back. Enjoy:
>
><http://jollyroger.kicks-ass.org/software/Resolve%20Aliases.zip>

In case you are interested, I ran the script and realized it didn't
report the number of aliases it found while searching. So I just updated
the script to show that, so you have a better indication of how long it
will take to process them. 

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#69601

On Sun, 8 Feb 2015 10:14:16 -0500, Jolly Roger wrote
(in article <cjpcq8Fm90uU6@mid.individual.net>):
 
>> I actually wrote exactly such a script a while back. Enjoy:
>> 
>> <http://jollyroger.kicks-ass.org/software/Resolve%20Aliases.zip>
> 
> In case you are interested, I ran the script and realized it didn't
> report the number of aliases it found while searching. So I just updated
> the script to show that, so you have a better indication of how long it
> will take to process them. 

Well, I took a look at your script and it gave me some ideas.  Thanks.  
However it appears to have a major shortcoming for what I want to do.  
This is due to the limitations of Applescript, not your code.

In the case of an alias to a file on an unmounted volume, The Finder's 
"Show Original" command will go out and mount the volume if it can;  
whereas the applescript property "original" of the Alias File class 
will only be populated if the volume is mounted.  Thus it reports 
aliases to files on other volumes as bad which are actually good.

Clearly, somewhere in the alias file record is information which points 
to the original pathname of the original file.  Else how could the 
finder know to mount the volume?  So I'd like to modify your algorithm 
to only report an alias as bad if the "original" property is empty 
_and_ the original volume is the same as the one the alias is on.
Also, to catch cloning errors where the alias is not re-homed to the 
corresponding file on the current drive, if the "original" is empty I'd 
like to at least display the original volume to differentiate aliases 
to files which have been deleted from those which merely pointing to a 
different volume.

Finally, even if the alias points to a nonexistent file on the same 
volume, I'd like to see the original path displayed to give me some 
hint of where to start to look for it :)

I don't see a way of doing this in applescript.  Perhaps reading in the 
raw alias file data and determining the original path that the Finder 
sees.  But I don't where in the file to find it.  And I'm not sure 
applescript will allow me to read in the alias file as a binary.


-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#69603

On 2015-02-08, Nelson <nelson@nowhere.com> wrote:
> On Sun, 8 Feb 2015 10:14:16 -0500, Jolly Roger wrote
> (in article <cjpcq8Fm90uU6@mid.individual.net>):
>  
>>> I actually wrote exactly such a script a while back. Enjoy:
>>> 
>>> <http://jollyroger.kicks-ass.org/software/Resolve%20Aliases.zip>
>> 
>> In case you are interested, I ran the script and realized it didn't
>> report the number of aliases it found while searching. So I just updated
>> the script to show that, so you have a better indication of how long it
>> will take to process them. 
>
> Well, I took a look at your script and it gave me some ideas.  Thanks.  
> However it appears to have a major shortcoming for what I want to do.  
> This is due to the limitations of Applescript, not your code.
>
> In the case of an alias to a file on an unmounted volume, The Finder's 
> "Show Original" command will go out and mount the volume if it can;  
> whereas the applescript property "original" of the Alias File class 
> will only be populated if the volume is mounted.  Thus it reports 
> aliases to files on other volumes as bad which are actually good.
> 
> Clearly, somewhere in the alias file record is information which points 
> to the original pathname of the original file.  Else how could the 
> finder know to mount the volume?  So I'd like to modify your algorithm 
> to only report an alias as bad if the "original" property is empty 
> _and_ the original volume is the same as the one the alias is on.

It doesn't seem like that will be possible with Finder since you would
need to examine the "original item" property to determine the original
volume. : /

> Also, to catch cloning errors where the alias is not re-homed to the 
> corresponding file on the current drive, if the "original" is empty I'd 
> like to at least display the original volume to differentiate aliases 
> to files which have been deleted from those which merely pointing to a 
> different volume.
>
> Finally, even if the alias points to a nonexistent file on the same 
> volume, I'd like to see the original path displayed to give me some 
> hint of where to start to look for it :)
>
> I don't see a way of doing this in applescript.  Perhaps reading in the 
> raw alias file data and determining the original path that the Finder 
> sees.  But I don't where in the file to find it.  And I'm not sure 
> applescript will allow me to read in the alias file as a binary.

Yeah. I think you'll need to do it in Cocoa/Carbon to do what you want.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#69594

On Sun, 8 Feb 2015 09:55:19 -0500, Jolly Roger wrote
(in article <cjpbmnFm90uU5@mid.individual.net>):

> On 2015-02-08, Nelson <nelson@nowhere.com> wrote:
>> 
>> Followup:  It looks like the problem, or at least part of the problem,  
>> is Carbon Copy Cloner.  Turns out drive D is a clone of drive C.  When 
>> I mount C, the alias on D resolves to the original on on C, _not_ the 
>> original on D. 
> 
> Aha. You hadn't mentioned this in your original post. The alias to a
> file/folder on C will always resolve to C because the original *is* on
> C. So it's operating as designed.
> 
>> If C is not mounted, the alias fails to resolve, which 
>> probably explains the "Connection Failed" message.
> 
> That's the behavior one would expect, though. C is a different volume
> from D, despite having a duplicate set of contents. And aliases always
> point to the *original* item.
> 
>> Well, that sucks.  I use CCC to back up all my external drives and make 
>> extensive use of aliases to, for example, categorize things without 
>> actually moving them into category folders (allows an item to appear in 
>> multiple categories).
>> 
>> To make things worse, C is a subsequent generation clone from an 
>> earlier, smaller drive so there are aliases that won't resolve on 
>> either.
>> 
>> For some reason these problems only appear when the the drive is 
>> accessed over the network.  When it is directly connected, the aliases 
>> in question resolve.  So it can't be all CCC's fault.
> 
> You're saying an alias to a file on C will resolve to a file on D when D
> is physically mounted, but not when D is mounted over the network? Are
> you sure about that? Hmmm...
> 
>> I wonder if there is a utility to straighten all this out.  If not, 
>> I'll probably try to write an Applescript to find all aliases and 
>> re-point them to the current drive.
> 
> That sounds like the correct solution to the problem since the aliases
> are still pointing to items on the other original volume(s).

I tried reproducing the errors but there are simply too many variables 
to get consistent results.  Some aliases work as expected, some open a 
file on a different volume, some don't open at all. It looks like it 
depends on the environment under which the alias was originally 
created.  I do notice that many of the cloned aliases will open the 
file on the clone rather than on the original disk.  But again, there 
is no pattern that I can detect.

There are aliases on this disk which go back to Panther at least and 
probably to OS 7.5 :)  Also some were created while the disk was 
directly connected and some while it was connected as a shared device 
over the network.  And, of course, it has been Carbon Copy Cloned 
multiple times.  There appears to be no rhyme or reason as to which 
file, if any, opens when I open an alias.  I'm sure with enough time I 
could sort it out but for now I think I'll just try your script.  
Thanks.

> I actually wrote exactly such a script a while back. Enjoy:
> 
> <http://jollyroger.kicks-ass.org/software/Resolve%20Aliases.zip>
> 
> 



-- 
Nelson

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.mac.system

csiph-web