Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

AFP urls in Mavericks are mounting as volumes

I just noticed that AFP URLs to paths on a server are being mounted as volumes in Mavericks. Previously, the AFP share would be mounted (if it wasn't already mounted) and then the specified path would be opened.


Example: afp://fileserver.example.com/ShareName/Folder1/Folder2/Folder3


In the example above, Mountain Lion would mount "ShareName" from "fileserver.example.com" and then open "Folder3".


Now, Mavericks mounts "Folder3" as a share.


Has anyone run across this issue and does anyone have a fix/work around?


JP

iMac, OS X Mavericks (10.9)

Posted on Dec 9, 2013 2:43 PM

Reply
26 replies

Dec 16, 2013 10:33 AM in response to oliwinton

Got this reply from Apple Bug Reporter.

Engineering has determined that this issue behaves as intended based on the following information:

The Finder has made this change. AFP/SMB now have an option and the Finder is setting it.

I've asked for claification and whether there is a way to return to the original behavior. I'd suggest complaining about it at http://bugreport.apple.com to see if we can get them to change it back. It really doesn't make sense to mount a URL's subfolder as a volume!


JP

Dec 16, 2013 10:42 AM in response to Jonathan Perel

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.

Dec 17, 2013 3:09 PM in response to etresoft

Previously it mounted the volume and then opened the referenced folder. If you didn't have acces to the root folder it wouldn't mount it. If you didn't have access to the leaf folder then it wouldn't open after mounting the root folder. It has always worked properly before this change.


So now how exactly can one user send a fully formed and functional url to an AFP share? The new "functionality" mounts a share named "share" every time an AFP URL with a leaf folder is clicked. This is a terrible change.

Dec 17, 2013 3:22 PM in response to Jonathan Perel

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.

Jan 22, 2014 6:51 AM in response to banyanfinn

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.

Jan 23, 2014 5:26 PM in response to etresoft

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.

Jan 23, 2014 5:42 PM in response to rameezie

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.

Jan 29, 2014 4:55 PM in response to Jonathan Perel

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.

AFP urls in Mavericks are mounting as volumes

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.