Professional Web Applications Themes

Using system functions Vs. Carbon functions - Mac Programming

Hello, Maybe this is a stupid question, but I'm curious. I'm developing a Carbon application and some days ago I needed to copy a file across different file servers. Finally, I was able to do that using MoreFilesX. My question is: is there a significant differente between to use Carbon File Manager functions, or to use system calls like : system ("cp \Library\myFile \myFolder"); Thanks in advance ! ......

  1. #1

    Default Using system functions Vs. Carbon functions

    Hello,

    Maybe this is a stupid question, but I'm curious. I'm developing a
    Carbon application and some days ago I needed to copy a file across
    different file servers. Finally, I was able to do that using
    MoreFilesX. My question is: is there a significant differente between
    to use Carbon File Manager functions, or to use system calls like :

    system ("cp \Library\myFile \myFolder");

    Thanks in advance ! ...
    Jorge Guest

  2. #2

    Default Re: Using system functions Vs. Carbon functions

    In article <google.com>,
    com (Jorge) wrote:
     

    There are two significant "problems" with using system() in this case.

    First, there's a very large performance overhead. Your system() call
    involves a fork, an exec, loading a shell, having the shell p its
    parameters, having the shell fork and exec, and finally having cp
    execute. So you create two processes to copy a file.

    Second, it's nearly impossible to correctly and safely use
    user-specified files with system(). This is because the string is passed
    straight to the shell, and the shell doesn't know that you want a file
    and then another file. Spaces in the filename will break the command, so
    your program would have to search for those and escape them. The same
    goes for a lot of other special characters. If you forget one, then
    you're potentially unsafe. Remember the iTunes installer bug a while
    back that wiped out a few people's hard drives? That was beacuse they
    forgot about this, didn't escape spaces, and a hard drive with a space
    in its name got pd as two arguments.

    In summary, system() is fine for things internal to your program if you
    don't mind it being slow (if you just have to copy one file it's
    probably no big deal), but should pretty much never be used with data
    from the user. (And if you use it with data coming in off the network
    from an untrusted source, you should have your computer taken away.)
    Michael Guest

  3. #3

    Default Re: Using system functions Vs. Carbon functions

    In article <mail-9C7F59.19313301102003localhost>,
    Michael Ash <com> wrote:
     
    >
    > There are two significant "problems" with using system() in this case.
    >
    > First, there's a very large performance overhead. Your system() call
    > involves a fork, an exec, loading a shell, having the shell p its
    > parameters, having the shell fork and exec, and finally having cp
    > execute. So you create two processes to copy a file.[/ref]

    Though it's worth pointing out that, on any Mac capable of running Mac
    OS X, the total overhead from this is going to be a small fraction of a
    second. Whether it's significant depends on how often the code is
    called.

    However, there are other reasons to think this approach is ugly, even if
    it only happens once in a while.

    This is one of them: 

    There's another: Resource forks. Using cp will lose them.

    --
    Tom "Tom" Harrington
    Macaroni, Automated System Maintenance for Mac OS X.
    Version 1.4: Best cleanup yet, gets files other tools miss.
    See http://www.atomicbird.com/
    Tom Guest

  4. #4

    Default Re: Using system functions Vs. Carbon functions

    In article <google.com>,
    com (Jorge) wrote:
     

    Resource forks has been pointed out. Also: Mac creator codes, Mac file
    types, and Finder comments.

    Also: Just read the source code in MoreFilesX: That logic is in there
    for a reason. (For example, taking advantage of server<->server file
    copy system calls if they are applicable.)

    Also: Internationalization: You should be using FindFolder(), rather
    than hard coding paths like "/Library" into your code.

    Also: error handling. What ever system does on cp failure, you can bet
    it is will be inappropriate for _your_ application.
    David Guest

  5. #5

    Default Re: Using system functions Vs. Carbon functions

    In article <sf.sbcglobal.net>,
    David Phillip Oster <org> wrote:
     

    Actually, /Library is called "/Library" on every system no matter what
    the language. The name changes in the Finder, but that's because the
    Finder is distilled in the foundries of the Dark Prince, composed of
    Pure Evil, and changes the name it shows to the user. Hard-coding paths
    such as /Library, /Applications, and so on is safe.

    Your other points are, of course, perfectly valid.
    Michael Guest

  6. #6

    Default Re: Using system functions Vs. Carbon functions

    In article <mail-95BD19.12420502102003localhost>,
    Michael Ash <com> wrote:
     
    >
    > Actually, /Library is called "/Library" on every system no matter what
    > the language. The name changes in the Finder, but that's because the
    > Finder is distilled in the foundries of the Dark Prince, composed of
    > Pure Evil, and changes the name it shows to the user. Hard-coding paths
    > such as /Library, /Applications, and so on is safe.[/ref]

    Is it doented as safe or is that just the case so far?

    G
    Gregory Guest

  7. #7

    Default Re: Using system functions Vs. Carbon functions

    David Phillip Oster wrote:
     
     [/ref]
     

    There's 'CpMac' from /Developer/Tools.
    But no user is guaranteed to have it ... :-(



    Mike Guest

  8. #8

    Default Re: Using system functions Vs. Carbon functions

    Thanks for your suggestions, guys ...

    The use of "/Library" was just an example ... I am really using the
    "system" function to mount a network volume. This is my code :

    system ("mount_afp afp://user:passwordserver/share
    /myVolumes/share");

    The reason is that I need to mount a volume silently, I mean, the user
    should not be aware that the application is connecting to a network
    volume. I explain you: my application is an usage tracker, it is
    saving to local logs the application usage activity and at the end of
    day, it connects to a central server and it makes a copy of the daily
    local log.

    As you can see, my mount point is different than default /Volumes
    folder, so Finder can't show it at the Desktop. It works fine (any
    suggestion about it?).

    Even though it works, I'm not sure if this is the best solution.
    Carbon functions like PBVolumeMount will show the volume at desktop.

    About system call usage I have another doubt: I have seen a "mount"
    function which is defined in mount.h, but no more doentation is
    provided. Can I use this function as an alternative to the "system"
    function?? ...

    Thanks in advance.
    Jorge


    Michael Ash <com> wrote in message news:<mail-95BD19.12420502102003localhost>... 
    >
    > Actually, /Library is called "/Library" on every system no matter what
    > the language. The name changes in the Finder, but that's because the
    > Finder is distilled in the foundries of the Dark Prince, composed of
    > Pure Evil, and changes the name it shows to the user. Hard-coding paths
    > such as /Library, /Applications, and so on is safe.
    >
    > Your other points are, of course, perfectly valid.[/ref]
    Jorge Guest

  9. #9

    Default Re: Using system functions Vs. Carbon functions

    In article <mail-95BD19.12420502102003localhost>,
    Michael Ash <com> wrote:
     
    >
    > Actually, /Library is called "/Library" on every system no matter what
    > the language. The name changes in the Finder, but that's because the
    > Finder is distilled in the foundries of the Dark Prince, composed of
    > Pure Evil, and changes the name it shows to the user. Hard-coding paths
    > such as /Library, /Applications, and so on is safe.[/ref]

    I've heard a lot about US companies getting software development done in
    other places. But it's mainly been places like India that I've heard
    about. When did Apple start getting software development done in Hell?
    And did they contract it out to some sort of infernal development house,
    or have they actually opened a new division?

    --
    Tom "Tom" Harrington
    Macaroni, Automated System Maintenance for Mac OS X.
    Version 1.4: Best cleanup yet, gets files other tools miss.
    See http://www.atomicbird.com/
    Tom Guest

  10. #10

    Default Re: Using system functions Vs. Carbon functions

    In article <google.com>,
    com (Jorge) wrote:
     

    Using for and exec is almost certainly better than system() in this
    case. Do you get any of user, password, server, share from outside of
    your program? If so, then the whole problem with proper escapes comes
    into play yet again. Using fork and exec will also let you get the
    return code from mount_afp which may be useful in case the mount fails.
     

    No doentation? 'apropos mount' says it's in chapter 2 of the man
    pages, and sure enough, 'man 2 mount' gives you the docs.
    Michael Guest

  11. #11

    Default Re: Using system functions Vs. Carbon functions

    In article <attbi.com>,
    Gregory Weston <com> wrote:
     
    > >
    > > Actually, /Library is called "/Library" on every system no matter what
    > > the language. The name changes in the Finder, but that's because the
    > > Finder is distilled in the foundries of the Dark Prince, composed of
    > > Pure Evil, and changes the name it shows to the user. Hard-coding paths
    > > such as /Library, /Applications, and so on is safe.[/ref]
    >
    > Is it doented as safe or is that just the case so far?[/ref]

    I can't find any doentation, I'm just quoting from memory what I
    recall reading, and also behavior that's seen so far.

    But hardcoded paths live everywhere in OS X. Consider Installer, and the
    massive quantity of Apple software that uses it. Installer lives on
    pathnames, there is probably not a single reference to FindFolder in it.
    Consider Cocoa, which has no FindFolder equivalent. Any change to these
    pathnames would break a huge amount of software.
    Michael Guest

  12. #12

    Default Re: Using system functions Vs. Carbon functions

    In article <tph-6D9277.10504502102003localhost>,
    Tom Harrington <no.spam.dammit.net> wrote:
     

    Based on my experiences with Apple software, my guess is than only the
    OS X Finder work has been subcontracted to Hell. And maybe the guys who
    came up with brushed metal.
    Michael Guest

  13. #13

    Default Re: Using system functions Vs. Carbon functions

    In article <mail-13E661.19471502102003localhost>,
    Michael Ash <com> wrote:
     
    > >
    > > Is it doented as safe or is that just the case so far?[/ref]
    >
    > I can't find any doentation, I'm just quoting from memory what I
    > recall reading, and also behavior that's seen so far.
    >
    > But hardcoded paths live everywhere in OS X. Consider Installer, and the
    > massive quantity of Apple software that uses it. Installer lives on
    > pathnames, there is probably not a single reference to FindFolder in it.
    > Consider Cocoa, which has no FindFolder equivalent. Any change to these
    > pathnames would break a huge amount of software.[/ref]

    Installer and Apple Software are mostly irrelevant as they are version-synced
    with the operating system. The question is largely relevant to cases where a
    single version of an app needs to work across multiple versions of the OS, which
    is, well, all 3rd party apps, and few Apple apps.

    Therefore, in a 3rd party app, I would highly recommend using FindFolder over
    hardcoded paths -- even in a Cocoa app.

    Also, it should be noted that FindFolder is in CoreServices, so the argument
    that it doesn't exist in Cocoa is somewhat suspect.

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  14. #14

    Default Re: Using system functions Vs. Carbon functions

    In article <mit.edu>,
    Miro Jurisic <org> wrote:
     

    Third-party apps can and do use Installer as their, well, installer. The
    hard-coded paths aren't in Installer itself, which knows nothing about
    /Library or anything else. The paths are in the files that Installer
    uses. So you'd have to totally redo the whole format for these files to
    be able to say "The folder formerly known as /Library". Installers could
    no longer be backwards or forwards compatible.

    Apple does sell some very expensive software on CD that is definitely
    not going to be version sync'd to the OS.
     

    It may be in a library that you get "for free" in a Cocoa app, but
    FindFolder does not lend itself to use in a Cocoa app. To get from what
    FindFolder returns to something you could pass to, say,
    stringWithContentsOfFile: requires serious contortions. So I stand by my
    statement that it is not part of Cocoa, even if it is technically
    accessable without pulling in Carbon.

    I get the distinct impression that a large part of why FindFolder is in
    Carbon is for the whole Classic-compatibility thing. If Apple were
    planning on having the locations of various important files be mutable,
    they would have provided Cocoa developers with a more straightforward
    way to get their paths.
    Michael Guest

  15. #15

    Default Re: Using system functions Vs. Carbon functions

    In article <mail-904F6E.22165902102003localhost>,
    Michael Ash <com> wrote:
     

    Even on Cocoa there are numerous folders for which calling FindFolder is better
    than constructing a raw path, because the latter requires depending on knowledge
    of the implementation of some part of the OS (e.g. Finder). Obviously the entire
    Classic domain fals into that category, but lest you think that is all, consider
    various trash folder types, or kCurrentUserRemoteFolderLocation. I would argue
    that at least for those folders, the bug is in the lack of education and
    accessibility in Cocoa, and I would encourage you to file it as such with Apple.

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  16. #16

    Default Re: Using system functions Vs. Carbon functions

    In article <mail-13E661.19471502102003localhost>,
    Michael Ash <com> wrote:
     

    In fact, Installer is and has been a fancy front-end to the command-line
    tool "pax". Which is borrowed from BSD, and follows the expected method
    of assuming hard-coded paths.

    --
    Tom "Tom" Harrington
    Macaroni, Automated System Maintenance for Mac OS X.
    Version 1.4: Best cleanup yet, gets files other tools miss.
    See http://www.atomicbird.com/
    Tom Guest

  17. #17

    Default Re: Using system functions Vs. Carbon functions

    In article <mit.edu>,
    Miro Jurisic <org> wrote:
     

    As always, meeroh, you have a good point. It would be a pretty trivial
    addition to, say, NSWorkspace. I still think hardcoding /Library is
    fine, but for these other folder types, I agree with you, and it is an
    omission that it's not available "in Cocoa".
    Michael Guest

  18. #18

    Default Re: Using system functions Vs. Carbon functions

    In article <mail-95BD19.12420502102003localhost>, Michael Ash
    <com> wrote:
     
    >
    > Actually, /Library is called "/Library" on every system no matter what
    > the language.[/ref]

    But are you guaranteed that /Library will always be /Library?

    On Mac OS X Server 1.0 through 1.2, it was actually /Local/Library. It
    could conceivably become that again, or move elsewhere. Applications
    that use FindFolder() will continue to do the right thing.
    Applications that don't will break.

    -- Chris

    --
    Chris Hanson, bDistributed.com, Inc. | Email: com
    Custom Application Development | Phone: +1-847-372-3955
    http://bdistributed.com/ | Fax: +1-847-589-3738
    http://bdistributed.com/Articles/ | Personal Email: com
    Chris Guest

  19. #19

    Default Re: Using system functions Vs. Carbon functions

    In article <mail-13E661.19471502102003localhost>, Michael Ash
    <com> wrote:
     

    See <Foundation/NSPathUtilities.h>:

    NSArray *paths =
    NSSearchPathForDirectoriesInDomains(NSLibraryDirec tory,
    NSLocalDomainMask,
    YES);

    This gets an array of search paths for the Library directory in the
    Local domain. (Which is probably just one element, "/Library".)

    -- Chris

    --
    Chris Hanson, bDistributed.com, Inc. | Email: com
    Custom Application Development | Phone: +1-847-372-3955
    http://bdistributed.com/ | Fax: +1-847-589-3738
    http://bdistributed.com/Articles/ | Personal Email: com
    Chris Guest

  20. #20

    Default Re: Using system functions Vs. Carbon functions

    In article <091020031651269947%com>,
    Chris Hanson <com> wrote:
     
    >
    > See <Foundation/NSPathUtilities.h>:
    >
    > NSArray *paths =
    > NSSearchPathForDirectoriesInDomains(NSLibraryDirec tory,
    > NSLocalDomainMask,
    > YES);
    >
    > This gets an array of search paths for the Library directory in the
    > Local domain. (Which is probably just one element, "/Library".)[/ref]

    I stand corrected.

    I wonder why I've never heard of this one before? I guess it's not very
    popular or something. Thanks for educating me. I hereby withdraw my
    support for hardcoding these paths.
    Michael Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Too many functions!!!
    By mikeDoh in forum Macromedia Flash Flashcom
    Replies: 5
    Last Post: August 2nd, 05:10 PM
  2. Help with cf functions
    By bongobuda in forum Macromedia ColdFusion
    Replies: 0
    Last Post: June 20th, 03:31 PM
  3. ADO Functions for ASP
    By hrothenb@bcpl.net in forum ASP Database
    Replies: 6
    Last Post: August 29th, 01:21 PM
  4. #10743 [Com]: class functions & PHP core functions inconsistently clash ;)
    By destes at ix dot netcom dot com in forum PHP Development
    Replies: 0
    Last Post: August 11th, 09:21 PM
  5. min and max functions
    By Alexander Ross in forum PHP Development
    Replies: 4
    Last Post: July 31st, 08:29 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139