Loading ...
Sorry, an error occurred while loading the content.
 

Re: why does vim change the file type?

Expand Messages
  • Bodhi
    This has nothing to do with carbonization , rather it has a bit to do with resource forks. Unless I have missed something fairly obvious, the command line
    Message 1 of 5 , Jun 4, 2003
      This has nothing to do with "carbonization", rather it has a bit to do
      with resource forks.

      Unless I have missed something fairly obvious, the command line version
      of Vim doesn't write resource forks. Mac OS 9 apps often require at
      least the existence of resource forks, if not specific content in the
      resource fork. In Mac OS X resource forks are supported by the Finder
      and most file systems, but are not required partially because UNIX apps
      in general usually don't expect them or know how to deal with them. I
      think that the official line that I read on the developer site was
      something like "don't rely on them but it is nice to put them in for
      backwards compatibility," which would seem to make sense in your
      situation.

      Options you have:
      -File a bug with the good folks doing Vim development and ask them to
      at least handle them gracefully if they are there. Having not done any
      research into the issue and just reading your email, it appears that
      there was a resource fork before you began editing it with Vim but when
      Vim saved the file it didn't save the existing resource fork. Perhaps
      the UNIX Vim source should check if it is Mac OS X and if the file has
      an existing resource fork make sure they save it. If someone wants to
      do this I can probably dig up what to call to do this - I would guess
      it is in CoreFoundation. (Sure there are things in Carbon, but who
      wants to link against that if they don't have to - esp in the UNIX
      version.)
      -Until then try the SetFile command line utility. It is installed with
      the Mac OS X Developer Tools in the /Developer/Tools directory. You
      could probably rig an alias so that you just say "make9Openable" and it
      runs SetFile with the appropriate arguments. Off the top of my head I
      don't know what the appropriate arguments are but I would try setting
      the -c and -d options. It probably doesn't matter what you set them to,
      it is probably just their existence that matters. See the SetFile
      manual page for examples (man SetFile in Terminal). That man page won't
      be there unless you have the Dev Tools and I think the Dev
      Documentation package installed.

      Hope that helps somewhat.

      On Tuesday, June 3, 2003, at 11:52, Dave Fortin wrote:

      > Hello,
      > I work at a manufacturing company in New Hampshire. My Job is to
      > write vectorscript code to automate the design of swimming pool liners
      > and covers. I just started here less than a year ago and I've been
      > introduced to the world of Macs. Always being a Solaris/Linux user
      > I've grown very attached to vim. I slowly got myself setup with VIM
      > on OS 9 and found it definitely more tedious then on a unix based OS.
      > Finally I convinced my boss to get me a new Mac with OS X (10.2.6) and
      > I feel write back at home. Actually I feel like I've moved into a
      > better place. Any who, the automated system I'm working with is using
      > MiniCad 6.0.4 which will only run on OS9. Eventually we want to get
      > into Vectorworks 10 but this is besides the point. In order to run
      > minicad 6.0.4 I must open the classic environment, which is not a
      > problem. Of course being a vim nut I do all of my developing in VIM
      > and love to be in the terminal. However the problem is when I open an
      > OS 9 textfile with vim and then edit and save it, I seem to loose
      > carbonization(?) and minicad 6.0.4 won't allow me to open that file
      > unless I reopen the file in an OS9 hex editor and save it. I don't
      > have to make any changes in the editor, I just save it so, I think,
      > the file will get re-carbonized or something. I'm wondering if there
      > is something I can set in VIM to preserve the file attributes so that
      > I don't have to do this tedious opening and closing of the file
      > multiple times before I use it. I know that If I open and make
      > changes to a file in BBEdit that I don't need to do the hex edit
      > thing. Any guesses or reasoning behind this?
      >
      > Thanks,
      > David Fortin.
      >
      >

      bodhi
    • Benji Fisher
      ... Perhaps the second item from the FAQ at http://macvim.swdev.org/OSX/#FAQ will help here. (I think the same advice applies for any version of vim and Mac
      Message 2 of 5 , Jun 4, 2003
        Bodhi wrote:
        > This has nothing to do with "carbonization", rather it has a bit to do
        > with resource forks.
        >
        > Unless I have missed something fairly obvious, the command line version
        > of Vim doesn't write resource forks. Mac OS 9 apps often require at
        > least the existence of resource forks, if not specific content in the
        > resource fork. In Mac OS X resource forks are supported by the Finder
        > and most file systems, but are not required partially because UNIX apps
        > in general usually don't expect them or know how to deal with them. I
        > think that the official line that I read on the developer site was
        > something like "don't rely on them but it is nice to put them in for
        > backwards compatibility," which would seem to make sense in your situation.
        >
        > Options you have:
        > -File a bug with the good folks doing Vim development and ask them to at
        > least handle them gracefully if they are there. Having not done any
        > research into the issue and just reading your email, it appears that
        > there was a resource fork before you began editing it with Vim but when
        > Vim saved the file it didn't save the existing resource fork. Perhaps
        > the UNIX Vim source should check if it is Mac OS X and if the file has
        > an existing resource fork make sure they save it. If someone wants to do
        > this I can probably dig up what to call to do this - I would guess it is
        > in CoreFoundation. (Sure there are things in Carbon, but who wants to
        > link against that if they don't have to - esp in the UNIX version.)
        > -Until then try the SetFile command line utility. It is installed with
        > the Mac OS X Developer Tools in the /Developer/Tools directory. You
        > could probably rig an alias so that you just say "make9Openable" and it
        > runs SetFile with the appropriate arguments. Off the top of my head I
        > don't know what the appropriate arguments are but I would try setting
        > the -c and -d options. It probably doesn't matter what you set them to,
        > it is probably just their existence that matters. See the SetFile manual
        > page for examples (man SetFile in Terminal). That man page won't be
        > there unless you have the Dev Tools and I think the Dev Documentation
        > package installed.
        >
        > Hope that helps somewhat.

        Perhaps the second item from the FAQ at
        http://macvim.swdev.org/OSX/#FAQ
        will help here. (I think the same advice applies for any version of vim and Mac
        OS.)

        # How can I keep file creators and other meta data when I save a file with vim?
        If you

        :set backupcopy=yes

        then you can edit files with Vim without changing their creator codes, so that
        opening them from the Finder will still launch the application that created
        them. New files that you write with Vim will still get Vim's creator code. For
        details, read

        :help 'backupcopy'

        HTH --Benji Fisher
      • Eugene Lee
        ... Correct. However, regarding the subject, the Mac file type information is stored in the file TYPE field of the HFS+ structure, and not in the resource
        Message 3 of 5 , Jun 4, 2003
          On Wed, Jun 04, 2003 at 11:20:35AM -0400, Benji Fisher wrote:
          :
          : Bodhi wrote:
          : >
          : >This has nothing to do with "carbonization", rather it has a bit to do
          : >with resource forks.
          : >
          : >Unless I have missed something fairly obvious, the command line version
          : >of Vim doesn't write resource forks.

          Correct. However, regarding the subject, the Mac file type information
          is stored in the file TYPE field of the HFS+ structure, and not in the
          resource fork.

          : Perhaps the second item from the FAQ at
          :
          : http://macvim.swdev.org/OSX/#FAQ
          :
          : will help here. (I think the same advice applies for any version of
          : vim and Mac OS.)

          Sounds like a winner to me. :-)


          --
          Eugene Lee
        • Dany St-Amant
          ... This problem should not be seen on the MACOS_CLASSIC version (even the carbonized one). I created a generic function mch_copy_file_attribute() [which is
          Message 4 of 5 , Jun 4, 2003
            Le mercredi, 4 jun 2003, à 12:38 Canada/Eastern, Eugene Lee a écrit :

            > On Wed, Jun 04, 2003 at 11:20:35AM -0400, Benji Fisher wrote:
            > :
            > : Bodhi wrote:
            > : >
            > : >This has nothing to do with "carbonization", rather it has a bit to
            > do
            > : >with resource forks.
            > : >
            > : >Unless I have missed something fairly obvious, the command line
            > version
            > : >of Vim doesn't write resource forks.
            >
            > Correct. However, regarding the subject, the Mac file type information
            > is stored in the file TYPE field of the HFS+ structure, and not in the
            > resource fork.

            This problem should not be seen on the MACOS_CLASSIC version (even
            the carbonized one). I created a generic function
            mch_copy_file_attribute()
            [which is now also used by the Windows version] to copy the resource
            fork
            and finder attribute from the original file. In don't remember why I
            remove
            the called from the MACOS_X version, but I'll take a look at it on the
            weekend.
            As for the plain UNIX version or X (as in Motif, Athena, ...), I don't
            know if there's
            some HFS function within Darwin which can be used.

            > : Perhaps the second item from the FAQ at
            > :
            > : http://macvim.swdev.org/OSX/#FAQ
            > :
            > : will help here. (I think the same advice applies for any version of
            > : vim and Mac OS.)
            >
            > Sounds like a winner to me. :-)

            Dany
          Your message has been successfully submitted and would be delivered to recipients shortly.