How to know if a file has been opened before?

  • I have implemented window state restauration in an app. This works fine for re-opening documents that were open when the app was last quit. What I now want to do is extend that functionality to files that were not necessarily open when the app was last quit, but simply that have been opened at any time before. I can't put state information into the files themselves, since they are files that need to remain clean and that are not "owned" by my app.

    From what I've researched so far the window state restoration feature won't extend the way I need it.

    I think NSURL's bookmarks feature could help out. I could create bookmark data, and save it, and then later, when a file is opened, check the cached bookmarkdata to see if one resolves to a URL that is equal to the url of the just opened file. That should even work if the file is moved between sessions. Is this the best way to do it though?

    The next question is, what is a handy way to keep track of the restoration data that goes with the URL, since that will have to be saved separately from the bookmark data. Using only the file name won't do, I need some kind of unique ID, or a unique URL that can be derived from the bookmark data.  I know I can think up a scheme, but I wonder if there is a proper way to do this, like obtaining a unique file ID.

    -António

    ----------------------------------------------------
    A merry heart does good like medicine
    ----------------------------------------------------
  • You can use extended attributes to attach information to a file. Maybe
    serialize your session state as a plist and use setxattr/getxattr to
    manipulate it. Follows the file as it's moved around.

    PS: it's recommended that names for your attribute following the java
    style reverse DNS. For example, Apple uses com.apple.FinderInfo

    On Mon, Jun 4, 2012 at 5:50 PM, Antonio Nunes <devlists...> wrote:
    > I have implemented window state restauration in an app. This works fine for re-opening documents that were open when the app was last quit. What I now want to do is extend that functionality to files that were not necessarily open when the app was last quit, but simply that have been opened at any time before. I can't put state information into the files themselves, since they are files that need to remain clean and that are not "owned" by my app.
    >
    > From what I've researched so far the window state restoration feature won't extend the way I need it.
    >
    > I think NSURL's bookmarks feature could help out. I could create bookmark data, and save it, and then later, when a file is opened, check the cached bookmarkdata to see if one resolves to a URL that is equal to the url of the just opened file. That should even work if the file is moved between sessions. Is this the best way to do it though?
    >
    > The next question is, what is a handy way to keep track of the restoration data that goes with the URL, since that will have to be saved separately from the bookmark data. Using only the file name won't do, I need some kind of unique ID, or a unique URL that can be derived from the bookmark data.  I know I can think up a scheme, but I wonder if there is a proper way to do this, like obtaining a unique file ID.
    >
    > -António
    >
    > ----------------------------------------------------
    > A merry heart does good like medicine
    > ----------------------------------------------------
  • On 05/06/2012, at 8:50 AM, Antonio Nunes wrote:

    > The next question is, what is a handy way to keep track of the restoration data that goes with the URL, since that will have to be saved separately from the bookmark data. Using only the file name won't do, I need some kind of unique ID, or a unique URL that can be derived from the bookmark data.  I know I can think up a scheme, but I wonder if there is a proper way to do this, like obtaining a unique file ID.

    I do something similar to map an SVG file to its thumbnail image, which is costly to generate, and is stored separately from the original file.

    Once I've created the thumbnail (or whatever data you want to associate with the file), I make a dictionary with the original file's URL as the key and a UUID string as the value. The UUID is then used as the filename for the thumbnail, which is stored in my Application Support folder. The dictionary is written out to a plist in the same location. Using a UUID avoids any possibility of accidentally creating a filename that clashes with one written earlier. The users never has to see these files so the obscure names don't matter.

    The dictionary plist of course, has to have a fixed name that you can load when your app starts up. Then as a file is opened, look up its "extra data" file via the dictionary and do whatever you want with it.

    I don't bother culling out thumbnail files that are never needed (if the original file is deleted for example), I just let the cache grow as disk space is super-abundant. You might want to give the user a way to discard this cache though if you were worried about it.

    --Graham
  • On Jun 4, 2012, at 5:50 PM, Antonio Nunes wrote:

    > I have implemented window state restauration in an app. This works fine for re-opening documents that were open when the app was last quit. What I now want to do is extend that functionality to files that were not necessarily open when the app was last quit, but simply that have been opened at any time before. I can't put state information into the files themselves, since they are files that need to remain clean and that are not "owned" by my app.

    I was recently looking at some old finder api's. and some of it involves fields that are pretty much obsolete.
    I was trying to figure out which flag bit setting corresponded to the locked checkbox in File>Get Info. At first I thought it was the name locked flag in finder flags. It turned out insted to be the node locked setting of a different flag. Name locked apparently had something to do with files in the old classic System folders.
    Assuming this bit is now never set, and not contents unpredictable, you could abscond with it as a user field associated with every file on the machine. Set it to mean whatever you want until someone else has the same idea.
  • On 4 Jun 2012, at 8:53 PM, Michael Hall wrote:

    > I was recently looking at some old finder api's. and some of it involves fields that are pretty much obsolete.
    > I was trying to figure out which flag bit setting corresponded to the locked checkbox in File>Get Info. At first I thought it was the name locked flag in finder flags. It turned out insted to be the node locked setting of a different flag. Name locked apparently had something to do with files in the old classic System folders.
    > Assuming this bit is now never set, and not contents unpredictable, you could abscond with it as a user field associated with every file on the machine. Set it to mean whatever you want until someone else has the same idea.

    Um. This is satire, right?

    — F
  • On Jun 4, 2012, at 9:00 PM, Fritz Anderson wrote:

    > On 4 Jun 2012, at 8:53 PM, Michael Hall wrote:
    >
    >> I was recently looking at some old finder api's. and some of it involves fields that are pretty much obsolete.
    >> I was trying to figure out which flag bit setting corresponded to the locked checkbox in File>Get Info. At first I thought it was the name locked flag in finder flags. It turned out insted to be the node locked setting of a different flag. Name locked apparently had something to do with files in the old classic System folders.
    >> Assuming this bit is now never set, and not contents unpredictable, you could abscond with it as a user field associated with every file on the machine. Set it to mean whatever you want until someone else has the same idea.
    >
    > Um. This is satire, right?
    >
    > — F
    >

    Well, probably not the best idea really. But similar fields used to actually be used sometime back in real coding. At least on machines I worked with way back. The OS even provided them.
    Probably why it occurred to me.
  • On Jun 4, 2012, at 8:53 PM, Michael Hall wrote:

    > I was recently looking at some old finder api's. and some of it involves fields that are pretty much obsolete.
    > I was trying to figure out which flag bit setting corresponded to the locked checkbox in File>Get Info. At first I thought it was the name locked flag in finder flags. It turned out insted to be the node locked setting of a different flag. Name locked apparently had something to do with files in the old classic System folders.
    > Assuming this bit is now never set, and not contents unpredictable, you could abscond with it as a user field associated with every file on the machine. Set it to mean whatever you want until someone else has the same idea.

    Please don’t abuse fields that are meant for some completely different purpose on the assumption that no one is still using it. Instead, just use an extended attribute. Much safer, since you’re actually using something for its intended purpose.

    Charles
  • On 5 Jun 2012, at 00:09, Stephen J. Butler wrote:

    > You can use extended attributes to attach information to a file. Maybe
    > serialize your session state as a plist and use setxattr/getxattr to
    > manipulate it. Follows the file as it's moved around.

    Thanks Stephen,

    I think the extended attributes are pretty persistent though, they'll follow the file around across to other computers, right? I wouldn't want that. I only need the data on the particular user's system. Starting to look like l'm probably better off devising my own scheme.

    -António

    -----------------------------------------------------------
    What you have inside you expresses itself through both your
    choice of words and the level of energy you assign to them.
    The more healed, whole and connected you feel inside,
    the more healing your words will be.

    --Rita Goswami
    -----------------------------------------------------------
  • On Tue, 05 Jun 2012 10:16:11 +1000 Graham Cox  wrote:
    >
    > I do something similar to map an SVG file to its thumbnail image, which is costly to generate, and is stored separately from the original file.
    >
    > Once I've created the thumbnail (or whatever data you want to associate with the file), I make a dictionary with the original file's URL as the key and a UUID string as the value. The UUID is then used as the filename for the thumbnail, which is stored in my Application Support folder. The dictionary is written out to a plist in the same location. Using a UUID avoids any possibility of accidentally creating a filename that clashes with one written earlier. The users never has to see these files so the obscure names don't matter.

    > I don't bother culling out thumbnail files that are never needed (if the original file is deleted for example), I just let the cache grow as disk space is super-abundant.

    Am I right in thinking that if the finder is used to move or duplicate the original file or a containing folder name is changed, you then need to re-create the thumbnail?
    If so then this is an interesting example of using memory to simplify program logic.
    Julius

    http://juliuspaintings.co.uk
  • On Tue, Jun 5, 2012 at 3:14 AM, Antonio Nunes <devlists...> wrote:
    > On 5 Jun 2012, at 00:09, Stephen J. Butler wrote:
    >
    >> You can use extended attributes to attach information to a file. Maybe
    >> serialize your session state as a plist and use setxattr/getxattr to
    >> manipulate it. Follows the file as it's moved around.
    >
    > Thanks Stephen,
    >
    > I think the extended attributes are pretty persistent though, they'll follow the file around across to other computers, right? I wouldn't want that. I only need the data on the particular user's system. Starting to look like l'm probably better off devising my own scheme.

    In general, yes. It won't follow if you upload to a website, say
    Dropbox, and then someone else downloads it. But if you copy it to a
    thumb drive and send it then it will.

    One thing you could try is to mix the two ideas. Generate a GUID for
    each file and store that in the extended attribute. Then use the GUID
    to lookup your session information in an application CoreData store or
    simple SQLite database.

    Then only the GUID follows the file around, and on another machine it
    won't have the session information and you can create it fresh. Also,
    you'll have to handle the case when a file doesn't have a GUID in its
    extended attributes and attach a new one.
  • On 05/06/2012, at 10:51 PM, julius wrote:

    >> I don't bother culling out thumbnail files that are never needed (if the original file is deleted for example), I just let the cache grow as disk space is super-abundant.
    >
    > Am I right in thinking that if the finder is used to move or duplicate the original file or a containing folder name is changed, you then need to re-create the thumbnail?
    > If so then this is an interesting example of using memory to simplify program logic.
    >

    Bookmarks track files as they move, but not when they are deleted. But yes, if the bookmark failed to resolve for some reason then the thumbnail just gets recreated. It is super-simple.

    --Graham
  • On Jun 5, 2012, at 6:45 AM, Stephen J. Butler wrote:

    > One thing you could try is to mix the two ideas. Generate a GUID for
    > each file and store that in the extended attribute. Then use the GUID
    > to lookup your session information in an application CoreData store or
    > simple SQLite database.

    But if someone makes a copy of the file, you've now got two documents with the same GUID, and if the settings for those documents change (as they will if the user opens both) you won't be able to keep track of them independently.

    "The only hard problems in computer science are naming things, cache invalidation, and off-by-one errors."
    —A co-worker of mine, no doubt quoting someone famous

    —Jens
  • On 5 Jun 2012, at 14:45, Stephen J. Butler wrote:

    > On Tue, Jun 5, 2012 at 3:14 AM, Antonio Nunes <devlists...> wrote:
    >> On 5 Jun 2012, at 00:09, Stephen J. Butler wrote:
    >>
    >>> You can use extended attributes to attach information to a file. Maybe
    >>> serialize your session state as a plist and use setxattr/getxattr to
    >>> manipulate it. Follows the file as it's moved around.
    >>
    >> Thanks Stephen,
    >>
    >> I think the extended attributes are pretty persistent though, they'll follow the file around across to other computers, right? I wouldn't want that. I only need the data on the particular user's system. Starting to look like l'm probably better off devising my own scheme.
    >
    > In general, yes. It won't follow if you upload to a website, say
    > Dropbox, and then someone else downloads it. But if you copy it to a
    > thumb drive and send it then it will.
    >
    > One thing you could try is to mix the two ideas. Generate a GUID for
    > each file and store that in the extended attribute. Then use the GUID
    > to lookup your session information in an application CoreData store or
    > simple SQLite database.
    >
    > Then only the GUID follows the file around, and on another machine it
    > won't have the session information and you can create it fresh. Also,
    > you'll have to handle the case when a file doesn't have a GUID in its
    > extended attributes and attach a new one.

    Thanks Stephen, I think that would be a bit overkill for my purposes though, since I really only want this info on the original machine. Also, Jens noted a possible issue with multiple copies of the same document. What I ended up doing is something not totally unlike what Graham suggested:

    I create a url bookmark that contains a UUID in the name on disk. Next to it I save the data required when reopening the file, with the same UUID incorporated in the name. The when a file is opened, I test the cached bookmarks for a match with the current document. If a match is found, then the UUID leads me to the restoration data, which is then loaded and used. Using bookmarks, rather than static URLs (as I think Graham does) has the benefit that it should be more robust when the file gets moved around between sessions: When reopening the file from another directory, the bookmark URL resolves to the new location, which is exactly what is needed.

    -António

    ----------------------------------------------------
    Energy is like a muscle,
    it grows stronger through being used.
    ----------------------------------------------------
previous month june 2012 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  
Go to today