 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / July 2005How to convert MAC paths to BSD (unix) paths?
Hi, I'm using libs that use UNIX fopen to open files but they require UNIX paths, i.e. if I do: FILE* pF = fopen("/Where/Ever/foo.txt", "rw"); // it works fine but if I do: FILE* pF = fopen("Macintosh HD:Where:Ever:foo.txt", "rw"); // it fails... pF is NULL. I managed to convert local MAC paths to BSD paths (paths like the ones above) but how to do that for network volumes? I have: "TRANSIT:Where:ever:foo.txt" that maps to "/Volumes/128.0.0.1/Where/Ever/foo.txt" in the terminal console (using 'ls' and 'cd') where TRANSIT is a Samba mounted volume on the server running Window$ 2003 (pro or server I don't remember well and don't care actually) which IP address is 128.0.0.1... Is there a way to convert this path to be able to send it to fopen or should I assume that there is no such function (just like there is no Carbon function to copy files) shame, shame, shame...? I'm using Mach-O project in CW 9.5 under OS X.3.5. Regards, MacPorter. This is not the answer you are looking for. But you can play with this conversion in Applescript. In Script Editor type: POSIX path of "some:Mac:Path" or (POSIX file "/My/Unix/path") as string and hit Run. But of course you want the API's underling this. Someone else? Robert > This is not the answer you are looking for. > [quoted text clipped - 8 lines] > > But of course you want the API's underling this. Someone else? See the APIs which take arguments of type CFURLPathStyle in CFURL.h. Hope this helps, Eric  SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > I'm using libs that use UNIX fopen to open files but they require UNIX > paths, i.e. if I do: [quoted text clipped - 18 lines] > should I assume that there is no such function (just like there is no > Carbon function to copy files) shame, shame, shame...? Look in Files.h You'll find a call that, given a Macintosh path return an FSRef, and given an FSRef returns a POSIX path. The target object has to exist to have an FSRef, so you often deal with pairs, where one element is the deepest director that exists, and the other element of the pair is a string that represents the rest of the path. SignatureDavid Phillip Oster If you mean ::FSRefMakePath I had already found it but the trouble is it requires to be connected to the volume to which the path refers... But I guess there is no way for the OS to map unresolved paths. Thanks anyway, I'm bound to use this function. David Phillip Oster a écrit : > > I'm using libs that use UNIX fopen to open files but they require UNIX > > paths, i.e. if I do: [quoted text clipped - 24 lines] > element is the deepest director that exists, and the other element of > the pair is a string that represents the rest of the path. I ran into the same problems, and in the end I wrote my own conversion class. I couldn't find a decent way to do it with any of the available APIs. The problem is even worse, because it depends on the way you mount the volume. I found that when you SMB mount instead of AFP, there is a hostname after the /Volumes, so SMB mounted /Volumes/hostname/Where/Ever/foo.txt. AFP mounted /Volumes/Where/Ever/foo.txt And since there a 2 ways to AFP mount (afp over TCP/IP - afp://hostname/... - and afp over AppleTalk - afp:/at/hostname/... -), I'm not sure if that makes an other difference. By the way, my conversion class is far from perfect, but it will be adapted if the need arises. For now it does what I need it for. With kind regards, Peter Paulus > If you mean ::FSRefMakePath I had already found it but the trouble is > it requires to be connected to the volume to which the path refers... [quoted text clipped - 32 lines] >>element is the deepest director that exists, and the other element of >>the pair is a string that represents the rest of the path. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.