lkml.org 
[lkml]   [1998]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Implementing Meta File information in Linux
    From
    In netuse.lists.linux-kernel you write:
    >This definitely is not possible in the directory fashion. Consider the
    >normal (for the Mac, at any rate) approach to storing editing info
    >(current line & col, for example) as a bit of information in the resource
    >fork of a source code file. This works just about perfectly, and trivial
    >programs simply ignore the resource information when they read from the
    >data fork (which contains the desired source code, in the usual ASCII
    >format). But in a directory system, there is no way to transparently
    >change "foo.c" into "foo.c/data", at least not without some tricks in the
    >VFS, or much smarter applications. (The closest we've ever come is the
    >emacs & vi local-data sections, which is hardly transparent.)

    Such things do not belong into the data files themselves. Can
    you imagine what things like these are doing to your backup
    concepts in a multi-user environment? Somebody touched a file
    with an editor, did not change anything but the cursor position
    in a ressource fork and the whole file goes to amanda the next
    night...

    Or what if I delete a user from my system. Imagine the system
    administrator scanning the whole filesystem for ressource forks
    where this particular user has stored now unneeded configuration
    data and stripping all these forks from the respective files -
    making changes to these files and forcing everything that user
    *ever* touched on backup the next night (which is exactly the
    opposite of the right thing to do, because I don't want to
    backup what is going to stay in my system, but what I am going
    to delete, just in case that user needs to be restored. Speaking
    of restores: Can you imagine the administration nightmare that
    is coming up, if you actually need to restore a user in your
    system WITH ALL THE RESSOURCE FORKS BELONGING TO THAT USER IN
    ALL FILES THAT THIS USER EVER TOUCHED? What if any of these
    files have been modified or renamed in the meantime?)

    And then there is the issue of permissions on files and on
    forks. There is no way I would let an editor store data in any
    fork of a file if that editor does not have write permission on
    that file. The editor would then have to store that information
    somewhere else, preferably in the users home directory, where
    any information local to that user belongs anyway.

    But then there is no need for resource forks storing such data
    anyway - which is a correct observation, because there isn't.

    Put user data in $HOME. Everything else is pain, great pain, NT
    pain.

    Kristian


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:4.053 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site