File Path Tracking

  • I have a program that keeps track of files by using the Unix Path to
    the file (as that is what is used to open and work with the files
    when the time comes).  I have run into a problem where when the files
    are stored on a network volume my program can occasionally no longer
    find the files because the path might have changed (i.e. "/Volumes/
    Data" becomes "/Volumes/Data 1"). This is particularly a problem with
    Fast User Switching as "Data" might be mounted a number of times.

    How might I deal with this type of issue?

    Daniel
  • Am 15.10.2007 um 21:10 schrieb Daniel Hazelbaker:
    > I have a program that keeps track of files by using the Unix Path
    > to the file (as that is what is used to open and work with the
    > files when the time comes).  I have run into a problem where when
    > the files are stored on a network volume my program can
    > occasionally no longer find the files because the path might have
    > changed (i.e. "/Volumes/Data" becomes "/Volumes/Data 1"). This is
    > particularly a problem with Fast User Switching as "Data" might be
    > mounted a number of times.
    >
    > How might I deal with this type of issue?

      As you noticed, file paths are not suitable for referencing files
    reliably. Check out Aliases, which can be used for this and are
    reliable. There's the CoreFoundation/Carbon Alias Manager API for
    this, or alternately you can use one of the Cocoa wrappers, like
    Nathan Day's NDAlias.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Correct me if I am wrong, but I don't think "Aliases" can cope with network mount name changes any better than Unix paths.  In fact, "Aliases" basically only work better than paths when used within one partition of a local hard disk that is formatted as HFS+.  In all other cases, an "Alias" is just a non-standard way to encode a path that adds complexity for no value.  Am I wrong ?
  • Am 15.10.2007 um 22:36 schrieb Erik Buck:
    > Correct me if I am wrong, but I don't think "Aliases" can cope with
    > network mount name changes any better than Unix paths.  In fact,
    > "Aliases" basically only work better than paths when used within
    > one partition of a local hard disk that is formatted as HFS+.  In
    > all other cases, an "Alias" is just a non-standard way to encode a
    > path that adds complexity for no value.  Am I wrong ?

      You are. Aliases will search for a file when it can't be referenced
    through a path or name, and thus will generally locate a file even
    when the drive has been unmounted or renamed, because they look at
    the actual names of the drives, and not at the name of the mount point.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Am 15.10.2007 um 21:17 schrieb Uli Kusterer:

    > Am 15.10.2007 um 21:10 schrieb Daniel Hazelbaker:
    >> I have a program that keeps track of files by using the Unix Path
    >> to the file (as that is what is used to open and work with the
    >> files when the time comes).
    >
    > Check out Aliases, which can be used for this and are reliable.

    Aliases don't work if you access the same file at the same path while
    one of the accesses is local while the other is remote, like:

    Machine 1:

    /Users/me/MyFile

    Machine 2:

    mount_afp machine1:/Users /Users
    /Users/me/MyFile

    An Alias created on machine 2 will hang on machine 1.

    I'm not aware of a reliable solution other than mounting shares at a
    fixed local path, e.g. by an entry in /etc/fstab.

    Markus

    - - - - - - - - - - - - - - - - - - -
    Dipl. Ing. Markus Hitter
    http://www.jump-ing.de/
  • On Oct 15, 2007, at 2:58 PM, Markus Hitter wrote:

    >
    > Am 15.10.2007 um 21:17 schrieb Uli Kusterer:
    >
    >> Am 15.10.2007 um 21:10 schrieb Daniel Hazelbaker:
    >>> I have a program that keeps track of files by using the Unix Path
    >>> to the file (as that is what is used to open and work with the
    >>> files when the time comes).
    >>
    >> Check out Aliases, which can be used for this and are reliable.
    >
    > Aliases don't work if you access the same file at the same path
    > while one of the accesses is local while the other is remote, like:

    Okay, well... here is the exact scenario I have:

    All media files (quicktime movies, still pictures, probably audio at
    some point, etc.) are stored on the network volume "HDCServer", which
    is shared from the server "fileserver".  What I could potentially
    have happen is this (psuedo):

    Machine 1:
    mount fileserver:HDCServer /Volumes/HDCServer

    Machine 2:
    mount fileserver:HDCServer /Volumes/HDCServer

    Machine 3 (FUS):
    User 1: mount fileserver:HDCServer /Volumes/HDCServer
    User 2: mount fileserver:HDCServer /Volumes/HDCServer\ 2

    The problem I run into is the final one.  When the HDCServer gets
    mounted to a different "Volumes" path it doesn't know how to find it
    anymore (to be specific, it gets access denied errors as User 2
    doesn't have access to User 1's HDCServer mount).  Now all of these
    "mounts" will be network based, however, I could foresee in the
    future a use of dual local/network for other libraries.

    As I understand you, this scenario would work since all are network
    instead of local.  If I try to mix local / network then I will run
    into issues.  Is there a way I can store the "alias data" (i.e. see
    com.apple.recentitems.plist) and then have the alias "system"
    translate the alias back into a regular unix path which I can open?
    In this recent items example all it stores is the alias data, so it
    seems like if two people have an alias to the same file, one local
    another via network, and they try to open the same file from the
    alias in their recent list they would come up with some kind of
    hanged state, but I have never heard of that happening?

    It would be nice to have it automatically try to mount the server if
    it is not, but I can live without that ability if it lets me pick up
    a "traveling" mount path.

    > Markus

    Daniel
  • Am 16.10.2007 um 01:26 schrieb Daniel Hazelbaker:

    > As I understand you, this scenario would work since all are network
    > instead of local.  If I try to mix local / network then I will run
    > into issues.

    Right.

    > Is there a way I can store the "alias data" (i.e. see
    > com.apple.recentitems.plist) and then have the alias "system"
    > translate the alias back into a regular unix path which I can open?

    Like Uli mentioned, the Alias mechanism should include such
    functionality already. I'm not sure, since I've never used Aliases
    programmatically.

    > In this recent items example all it stores is the alias data, so it
    > seems like if two people have an alias to the same file, one local
    > another via network, and they try to open the same file from the
    > alias in their recent list they would come up with some kind of
    > hanged state, but I have never heard of that happening?

    Probably, because Apple recommends to work either all local or all
    network. The kind of setup to put a few Homes on each of the
    participating computers while mounting them remotely on the other
    machines is often seen in Unix-only networks but very rarely with Mac
    OS X.

    Markus

    - - - - - - - - - - - - - - - - - - -
    Dipl. Ing. Markus Hitter
    http://www.jump-ing.de/
  • On 16 Oct 2007, at 08:43, Markus Hitter wrote:

    >
    >> In this recent items example all it stores is the alias data, so
    >> it seems like if two people have an alias to the same file, one
    >> local another via network, and they try to open the same file from
    >> the alias in their recent list they would come up with some kind
    >> of hanged state, but I have never heard of that happening?
    >
    > Probably, because Apple recommends to work either all local or all
    > network. The kind of setup to put a few Homes on each of the
    > participating computers while mounting them remotely on the other
    > machines is often seen in Unix-only networks but very rarely with
    > Mac OS X.
    >

    I did this when I worked for a University (admin and root had local
    home directories, everyone else accessed a file server for theirs,
    which is actually less distributed (and less insane) than the NIS/NFS-
    style setup you describe) and never found any problems, but then I'm
    not sure what problems might be expected.  I suppose the point is
    that sharing an alias between a 'local' and 'network' user is not
    guaranteed to work, but then that rarely if ever happened because [i]
    no-one logged in at the file server locally and [ii]sharing paths or
    files is much more intuitive than sharing aliases, because the former
    are descriptive and the latter is opaque.

    Cheers,
    Graham.
  • Am 16.10.2007 um 10:25 schrieb Graham J Lee:

    > (admin and root had local home directories, everyone else accessed
    > a file server for theirs, which is actually less distributed (and
    > less insane) than the NIS/NFS-style setup you describe)

    Thousands of Homes on a single server can be pretty hefty and
    distributing this evenly to all the workstations gives a long list of
    (auto)mounts, but makes a giant file server obsolete, as well.

    > I suppose the point is that sharing an alias between a 'local' and
    > 'network' user is not guaranteed to work, but then that rarely if
    > ever happened

    The Dock uses Aliases, for example. As do some of the right side
    menus, e.g. Classic. The latter stops the Finder from loading if it
    points to an unresolvable volume.

    Markus

    - - - - - - - - - - - - - - - - - - -
    Dipl. Ing. Markus Hitter
    http://www.jump-ing.de/
  • On 16 Oct 2007, at 10:23, Markus Hitter wrote:

    >
    > Am 16.10.2007 um 10:25 schrieb Graham J Lee:
    >
    >> (admin and root had local home directories, everyone else accessed
    >> a file server for theirs, which is actually less distributed (and
    >> less insane) than the NIS/NFS-style setup you describe)
    >>
    >
    > Thousands of Homes on a single server can be pretty hefty and
    > distributing this evenly to all the workstations gives a long list
    > of (auto)mounts, but makes a giant file server obsolete, as well.
    >

    It makes the administration easier though because there are fewer
    'important' systems; the workstations are just like heavy Sun Rays.

    >> I suppose the point is that sharing an alias between a 'local' and
    >> 'network' user is not guaranteed to work, but then that rarely if
    >> ever happened
    >
    > The Dock uses Aliases, for example.

    I don't know if it's because the aliases also refer to the file by
    path or because MCX preferences do some magic rewriting, but that
    never caused a problem.

    > As do some of the right side menus, e.g. Classic. The latter stops
    > the Finder from loading if it points to an unresolvable volume.
    >

    Ah, well I had a simple and effective approach to Classic support ;-)

    Cheers,
    Graham.
  • Summary: Thanks all for the input.  It is not optimal but it sounds
    like storing the alias data as well as the unix path is my solution.
    If the unix path does not work (most of the time it will) then
    attempt to use the alias functions to determine what the new path is.

    Regards,
    Daniel

    On Oct 16, 2007, at 12:43 AM, Markus Hitter wrote:

    >
    > Am 16.10.2007 um 01:26 schrieb Daniel Hazelbaker:
    >
    >> As I understand you, this scenario would work since all are
    >> network instead of local.  If I try to mix local / network then I
    >> will run into issues.
    >
    > Right.
    >
    >> Is there a way I can store the "alias data" (i.e. see
    >> com.apple.recentitems.plist) and then have the alias "system"
    >> translate the alias back into a regular unix path which I can open?
    >
    > Like Uli mentioned, the Alias mechanism should include such
    > functionality already. I'm not sure, since I've never used Aliases
    > programmatically.
    >
    >> In this recent items example all it stores is the alias data, so
    >> it seems like if two people have an alias to the same file, one
    >> local another via network, and they try to open the same file from
    >> the alias in their recent list they would come up with some kind
    >> of hanged state, but I have never heard of that happening?
    >
    > Probably, because Apple recommends to work either all local or all
    > network. The kind of setup to put a few Homes on each of the
    > participating computers while mounting them remotely on the other
    > machines is often seen in Unix-only networks but very rarely with
    > Mac OS X.
    >
    >
    > Markus
    >
    > - - - - - - - - - - - - - - - - - - -
    > Dipl. Ing. Markus Hitter
    > http://www.jump-ing.de/
    >
    >
    >
    >
    >
  • Daniel Hazelbaker wrote:

    > Summary: Thanks all for the input.  It is not optimal but it sounds
    > like storing the alias data as well as the unix path is my solution.
    > If the unix path does not work (most of the time it will) then
    > attempt to use the alias functions to determine what the new path is.

    Since the default behavior of alias resolution is to check the stored
    path first, why bother with an explicit path check beforehand? The
    whole point of the alias mechanism is to robustly track files over
    extended periods of time. Resolve the alias, and the system will tell
    you in the process of that resolution whether the file has moved (and
    thus the alias needs to be resaved for optimal efficiency). Bob's
    your metaphorical uncle.
  • Am 17.10.2007 um 23:53 schrieb Gregory Weston:

    > Since the default behavior of alias resolution is to check the
    > stored path first, why bother with an explicit path check beforehand?

    The default behaviour is to mount the server before checking the
    path. This works often, but not always.

    Markus

    - - - - - - - - - - - - - - - - - - -
    Dipl. Ing. Markus Hitter
    http://www.jump-ing.de/
  • This is not the default behaviour when resolving an alias
    programmatically.  You can choose how you want the alias to be
    resolved, the order in which alias matches are searched, and whether
    resolving/matching the alias mounts any file system (disk images,
    network shares, et cetera).

    Ack, at 10/18/07, Markus Hitter said:

    > The default behaviour is to mount the server before checking the
    > path. This works often, but not always.

    --

    Sincerely,
    Rosyna Keller
    Technical Support/Carbon troll/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People

    It's either this, or imagining Phil Schiller in a thong.
previous month october 2007 next month
MTWTFSS
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        
Go to today