AFP urls in Mavericks are mounting as volumes

Yea! Me too.

Would love a workaround.

Jonathan Perel wrote:

It really doesn't make sense to mount a URL's subfolder as a volume!

It doesn't make sense to do it any other way. What if you don't have permissions for the parent paths? The user would still be able to navigate to them and potentially lock up the Finder. You are telling it to mount a leaf path and it is doing what you ask. Why would it need to be fixed? If you can mount the share, just mount the share.

I fully agree with Jonathan.

My workflow includes clicking on AFP links about times a day.

I don't really want 10 share points mounted thanks...

Jonathan Perel wrote:

So now how exactly can one user send a fully formed and functional url to an AFP share?

But why would you do that to start with? Why not just mount the share? You can use autofs to do that automatically. Or you could use alises for deep references. It just sounds like you have gotten used to a convoluted way to do something and never noticed or tried better ways. Better ways do exist.

I am having the same problem and its so annoying. I hope this gets fixed immediately.

The share is already mounted. When you click a link to the file, it mounts that folder as if its a separate share when it is only a folder. Not sure how this is convoluted but please explain the better way to get around this.

I have recently run across this new behavior in our office after upgrading a few machines to Mavericks. It's a PITA for our workflow, too. I'd appreciate any info about workarounds.

banyanfinn wrote:

I'd appreciate any info about workarounds.

You mean any additional info about workarounds other than the ones already provided? I assume you have tried those and found them insufficient? The system is working as designed and better than it did before. If your workflow depended on buggy behaviour from the past, you will have to change your workflow.

Which solutions were provided, Etresfot? You are the one that stated better ways do exist. What is considererd "buggy behavior? Simpling clicking a link to a file is buggy?

If there are this many complaints about the same issue, then the system is notworking better than it did before. If you can't help solve the problem or even come close to undersanding it, why are even bother with your unhelpful responses.

rameezie wrote:

Which solutions were provided, Etresfot? You are the one that stated better ways do exist.

The ones I mentioned before. Using autofs or aliases.

What is considererd "buggy behavior? Simpling clicking a link to a file is buggy?

If given a direct URL, it should mount that URL, not some other URL and then open some folder within.

If there are this many complaints about the same issue, then the system is notworking better than it did before. If you can't help solve the problem or even come close to undersanding it, why are even bother with your unhelpful responses.

How many complaints? Four? And the only response to the issue that actually provide solutions is the "unhelpful" one? I get it, the only "helpful" response is a "me too" response. Sorry. No can do. I guess you will have to live with my answers that merely solve the issue, but do nothing worthwhile.

Nope. You still don't understand and are still unhelpful.

Yeah, sorry etresoft but I don't think you understand.

Suppose you have a very large amount of data shared, in a very complicated hierarchy. It goes down countless levels, clients/<client>/<projectID>/<project phase>/<type of file>/etc.

I am currently working on something seven layers deep. There are at least hundreds of projects from dozens of clients.

Now suppose that Apple gives you a product that works a given way. In this case, sharing URLs mounts the root share and navigates you straight to a folder within that share. If you are working on a team and one person needs another person to use their specialized talent to do something to a file (say a retoucher), then they can copy/paste a URL and send it via iChat. That person goes straight there. No problem.

Now, though, suppose that Apple changes this behavior, behavior that people have been using for YEARS, such that they now are spit out at the specific folder with the rest of the path missing. The final file needs to go to a location that is up a folder or two? Uh-oh! You have no idea where it goes.

You now get to read the URL with your eyes and follow along in the finder (slow) for every single file you work with on a daily basis.

Now, when you go to complain about this behavior, you are told by someone that the way you've always done it, the way Apple made it, and the way that never seemed buggy, but 'just worked', was 'buggy', and that this new method, which is completely incompatible with the workflow you have developed, is 'correct'.

Excuse me?

I'd say that they way it has always worked for years is 'expected behavior', and there should at the very least be a way to revert to that behavior.

Do you understand now?

Sharing paths doesn't do much good if you need to have the file within the context of the hierarchy. I previously could control permissions at the share level, not at the arbitrary folder level. It used to mount the share that the file was in and take you there, including any folders within that share between the file and the share. It didn't let you see anything above the share. This new method essentially creates 'shares' at any arbitrary folder above the file you link, and doesn't let you see above that level, even if that folder and several more of them all exist within the same share.

It is well-known that small changes can be amplified into what is perceived as insurmountable obstacles when articulation work is involved. You are welcome to send feedback to Apple to request it be changed back to the old behaviour.