Re: [fonc] Unsolved problem solved in mac os x
Next: what if the file system operation is a copy paste cut - old operation? Sounds like we may be back to copying garbage collectors. On Oct 5, 2014 6:00 PM, "John Carlson" wrote: > This Mac OSX feature sounds exactly what I am looking for. Thanks! > -- Forwarded message -- > From: "JD Paley" > Date: Oct 5, 2014 10:05 AM > Subject: A response (post rejected by autom. list mgr) > To: "John Carlson" > Cc: > > Subject: Re: [fonc] Unsolved problem in computer science? Fixing shortcuts. > > Thought this was solved with two-way binding - bidirectional links so that > a pointer gets updated whenever the linked element moves. Or as in OS X > Finder's Aliases (vs Sym/Hard Links) keeping in the link file file both the > higher- and lower-level addresses (the resource name and its inode number). > When a followed Alias mismatches its target name, a search for the univocal > inode gets triggered. > > JD Paley > > ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Unsolved problem solved in mac os x
This Mac OSX feature sounds exactly what I am looking for. Thanks! -- Forwarded message -- From: "JD Paley" Date: Oct 5, 2014 10:05 AM Subject: A response (post rejected by autom. list mgr) To: "John Carlson" Cc: Subject: Re: [fonc] Unsolved problem in computer science? Fixing shortcuts. Thought this was solved with two-way binding - bidirectional links so that a pointer gets updated whenever the linked element moves. Or as in OS X Finder's Aliases (vs Sym/Hard Links) keeping in the link file file both the higher- and lower-level addresses (the resource name and its inode number). When a followed Alias mismatches its target name, a search for the univocal inode gets triggered. JD Paley ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
That sounds like a good idea. I like it because it operates on more than one dataset. However, we'll need to track paths as well as just references. This is already done for circular references in garbage collectors, so it might be just the ticket. What I am wondering is if this sort of thing could be handled by a possibly modified Journaling file system. If the journal maintains the important stuff, couldn't it be looked at for any folder moves which affect shortcuts? On Oct 5, 2014 2:21 PM, "Tristan Slominski" wrote: > One thing that comes to mind are copying garbage collectors which need to > keep track of references while moving objects around. Probably looking into > how that is solved will provide some insight. > > On Sun, Oct 5, 2014 at 12:35 PM, John Carlson wrote: > >> Not obvious to me. Are you saying a folder of shortcuts? A shortcut to >> a folder? A shortcut to a shortcut to a folder? Instead of using >> indirect addressing, can you put it in terms of folders and shortcuts, or >> do we need a third type of object? And how does this apply to a general >> graph problem? Are you speaking of URNs? A directory of hard links? >> That seems to make the most sense to me, and would bring in the third type >> of object. Can you really make a hard link to a directory, and expect it >> to work? I'm not thinking of something with two levels, I am thinking of a >> multilevel problem, where the shortcuts go really deep, like from a desktop >> to somewhere into program files. If I rename a program files folder, what >> happens to my shortcuts? If you like I can put this into Linux/BSD terms >> which I am more comfortable with. I am trying to address it to a larger >> audience than that though. >> >> On Sun, Oct 5, 2014 at 8:49 AM, Miles Fidelman < >> mfidel...@meetinghouse.net> wrote: >> >>> Isn't the obvious answer to use indirect addressing via a directory? >>> >>> John Carlson wrote: >>> To put the problem in entirely file system terminology, What happens to a folder with shortcuts into it when you move the folder? How does one automatically repoint the shortcuts? Has this problem been solved in computer science? On linux, the shortcuts would be symbolic links. I had a dream about smallstar when I was thinking about this. The author was essentially asking me how to fix it. He was showing me a hierarchy, then he moved part of the hierarchy into a subfolder and asked me how to automate it--especially the links to the original hierarchy. In language terms, this would be equivalent of refactoring a class which gets dropped down into an inner class. This might be solved. I'm not sure. This would be a great problem to solve on the web as well...does Xanadu do this? I think the solution is to maintain non-persistent nodes which are computed at access time, but I'm not entirely clear. I have no idea why I am posting this to cap-talk. There may be some capability issues that I haven't thought of yet. Or perhaps the capability folks have already solved this. For your consideration, John Carlson ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc >>> >>> >>> -- >>> In theory, there is no difference between theory and practice. >>> In practice, there is. Yogi Berra >>> >>> ___ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >>> >> >> >> ___ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
One thing that comes to mind are copying garbage collectors which need to keep track of references while moving objects around. Probably looking into how that is solved will provide some insight. On Sun, Oct 5, 2014 at 12:35 PM, John Carlson wrote: > Not obvious to me. Are you saying a folder of shortcuts? A shortcut to > a folder? A shortcut to a shortcut to a folder? Instead of using > indirect addressing, can you put it in terms of folders and shortcuts, or > do we need a third type of object? And how does this apply to a general > graph problem? Are you speaking of URNs? A directory of hard links? > That seems to make the most sense to me, and would bring in the third type > of object. Can you really make a hard link to a directory, and expect it > to work? I'm not thinking of something with two levels, I am thinking of a > multilevel problem, where the shortcuts go really deep, like from a desktop > to somewhere into program files. If I rename a program files folder, what > happens to my shortcuts? If you like I can put this into Linux/BSD terms > which I am more comfortable with. I am trying to address it to a larger > audience than that though. > > On Sun, Oct 5, 2014 at 8:49 AM, Miles Fidelman > wrote: > >> Isn't the obvious answer to use indirect addressing via a directory? >> >> John Carlson wrote: >> >>> To put the problem in entirely file system terminology, What happens to >>> a folder with shortcuts into it when you move the folder? How does one >>> automatically repoint the shortcuts? Has this problem been solved in >>> computer science? On linux, the shortcuts would be symbolic links. >>> >>> I had a dream about smallstar when I was thinking about this. The >>> author was essentially asking me how to fix it. He was showing me a >>> hierarchy, then he moved part of the hierarchy into a subfolder and asked >>> me how to automate it--especially the links to the original hierarchy. >>> >>> In language terms, this would be equivalent of refactoring a class which >>> gets dropped down into an inner class. This might be solved. I'm not sure. >>> >>> This would be a great problem to solve on the web as well...does Xanadu >>> do this? >>> >>> I think the solution is to maintain non-persistent nodes which are >>> computed at access time, but I'm not entirely clear. >>> >>> I have no idea why I am posting this to cap-talk. There may be some >>> capability issues that I haven't thought of yet. Or perhaps the capability >>> folks have already solved this. >>> >>> For your consideration, >>> >>> John Carlson >>> >>> >>> ___ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >>> >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. Yogi Berra >> >> ___ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
Not obvious to me. Are you saying a folder of shortcuts? A shortcut to a folder? A shortcut to a shortcut to a folder? Instead of using indirect addressing, can you put it in terms of folders and shortcuts, or do we need a third type of object? And how does this apply to a general graph problem? Are you speaking of URNs? A directory of hard links? That seems to make the most sense to me, and would bring in the third type of object. Can you really make a hard link to a directory, and expect it to work? I'm not thinking of something with two levels, I am thinking of a multilevel problem, where the shortcuts go really deep, like from a desktop to somewhere into program files. If I rename a program files folder, what happens to my shortcuts? If you like I can put this into Linux/BSD terms which I am more comfortable with. I am trying to address it to a larger audience than that though. On Sun, Oct 5, 2014 at 8:49 AM, Miles Fidelman wrote: > Isn't the obvious answer to use indirect addressing via a directory? > > John Carlson wrote: > >> To put the problem in entirely file system terminology, What happens to a >> folder with shortcuts into it when you move the folder? How does one >> automatically repoint the shortcuts? Has this problem been solved in >> computer science? On linux, the shortcuts would be symbolic links. >> >> I had a dream about smallstar when I was thinking about this. The author >> was essentially asking me how to fix it. He was showing me a hierarchy, >> then he moved part of the hierarchy into a subfolder and asked me how to >> automate it--especially the links to the original hierarchy. >> >> In language terms, this would be equivalent of refactoring a class which >> gets dropped down into an inner class. This might be solved. I'm not sure. >> >> This would be a great problem to solve on the web as well...does Xanadu >> do this? >> >> I think the solution is to maintain non-persistent nodes which are >> computed at access time, but I'm not entirely clear. >> >> I have no idea why I am posting this to cap-talk. There may be some >> capability issues that I haven't thought of yet. Or perhaps the capability >> folks have already solved this. >> >> For your consideration, >> >> John Carlson >> >> >> ___ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. Yogi Berra > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
Isn't the obvious answer to use indirect addressing via a directory? John Carlson wrote: To put the problem in entirely file system terminology, What happens to a folder with shortcuts into it when you move the folder? How does one automatically repoint the shortcuts? Has this problem been solved in computer science? On linux, the shortcuts would be symbolic links. I had a dream about smallstar when I was thinking about this. The author was essentially asking me how to fix it. He was showing me a hierarchy, then he moved part of the hierarchy into a subfolder and asked me how to automate it--especially the links to the original hierarchy. In language terms, this would be equivalent of refactoring a class which gets dropped down into an inner class. This might be solved. I'm not sure. This would be a great problem to solve on the web as well...does Xanadu do this? I think the solution is to maintain non-persistent nodes which are computed at access time, but I'm not entirely clear. I have no idea why I am posting this to cap-talk. There may be some capability issues that I haven't thought of yet. Or perhaps the capability folks have already solved this. For your consideration, John Carlson ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Unsolved problem in computer science? Fixing shortcuts.
To put the problem in entirely file system terminology, What happens to a folder with shortcuts into it when you move the folder? How does one automatically repoint the shortcuts? Has this problem been solved in computer science? On linux, the shortcuts would be symbolic links. I had a dream about smallstar when I was thinking about this. The author was essentially asking me how to fix it. He was showing me a hierarchy, then he moved part of the hierarchy into a subfolder and asked me how to automate it--especially the links to the original hierarchy. In language terms, this would be equivalent of refactoring a class which gets dropped down into an inner class. This might be solved. I'm not sure. This would be a great problem to solve on the web as well...does Xanadu do this? I think the solution is to maintain non-persistent nodes which are computed at access time, but I'm not entirely clear. I have no idea why I am posting this to cap-talk. There may be some capability issues that I haven't thought of yet. Or perhaps the capability folks have already solved this. For your consideration, John Carlson ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
