HFS+ Support

  • Kevin Hendrickson

    I downloaded the latest source of MacCVS PRO yesterday, got it to build under CW7 (with some futzing) and found that there is no support for HFS+, so the maximum filename length is still 31 char. Unfortunately I'm accessing a repository that is used for Unix and NT development, which do not suffer from this old HFS limitation. Neither should we. :-) So I'm wondering what the status is on getting HFS+ support into MacCVS Pro. I've been in contact with Ram Rajadhyaksha who isn't working on this anymore but he said all we have to do is add an HFS/HFS+ abstraction layer and change all the old API calls. Is anyone working on this? Need any help (yes, I'm volunteering)?

    • Simon Fraser

      Simon Fraser - 2002-02-06

      Ah, he makes it sound so easy. It's not.

      I agree that we should abstract out FSSpecs into a class that can wrap
      an FSRef or whatever, but FSSpecs are used all over the code. In addition,
      any implementation of that class has to deal with the fact that FSRefs cannot
      refer to non-existent file system entities (so you can use them to refer to the
      location at which you want to create a file). It's not obvious from code when FSSpecs
      are being used this way.

      For a purely Mac OS X solution, it might be better to use CFURLs, which would also
      eliminate a lot of path<->file spec conversions. But these should not be used under
      9, because they suffer from the multiple-volume-with-the-same-name problem.

      If you're willing to try, good luck! I would advise you, however, to discuss your
      proposed solution on this list before starting out.

      • Kevin Hendrickson

        Heh. I think he was just giving a brief summary of a reasonable approach to take. I've looked at the source and know that it is a very serious undertaking. :-) I'll do a bit of poking around and let you know what I come up with.

    • Glenn L. Austin

      Glenn L. Austin - 2002-06-26

      The code for long file names has been checked in, but it is not yet on the main trunk (or been *fully* tested!).  You need to get the tag "GLA_Long_File_Name-branch" to get all of the changes to support long file names and optionally UTF-8 file names.

      • Reid Ellis

        Reid Ellis - 2002-07-08

        Any chance of the Code Warrior 8 project being part of this branch? Or did you have to change the project file too?

      • Reid Ellis

        Reid Ellis - 2002-07-08

        When I try to build crypto++ on the GLA_Long_File_Name branch, I get the following link errors:

        Link Error   : undefined 'DisposeTextToUnicodeInfo' (code)
        Referenced from '__msl_text2unicode' in MSL_All_PPC.Lib

        Link Error   : undefined 'ConvertFromTextToUnicode' (code)
        Referenced from '__msl_text2unicode' in MSL_All_PPC.Lib

        Link Error   : undefined 'CreateTextToUnicodeInfoByEncoding' (code)
        Referenced from '__msl_text2unicode' in MSL_All_PPC.Lib

        Link Error   : undefined 'UpgradeScriptInfoToTextEncoding' (code)
        Referenced from '__msl_get_system_encoding' in MSL_All_PPC.Lib

        Is this specific to the GLA_Long_File_Name branch? Note that this is using Code Warrior 7. Could some of the of newer, possibly Code Warrior 8-dependent code be "leaking" over?

    • Glenn L. Austin

      Glenn L. Austin - 2003-02-26

      The latest trunk (3.0a3) has all of the long file name support (including the correct libraries in the projects).


      • Reid Ellis

        Reid Ellis - 2003-02-27

        Is there a binary of 3.0a3 anywhere? Does MacCVSPro-2.7f1.sit have long filename support as well?

        I've been using a home-built GLA_Long_File_Name-branch app for the last several months, and just realized my team doesn'thave the long_filename support (I checked in a long filename!). Is there a binary anywhere I can point them to, or should I just give them a copy of my custom-built one?

        I'm going to try updating to 3.0a3 and build that, just to see how it goes. We're all using MacOS X, so MacOS 9 compatibility is not a big deal.

        Are there any patched for switching over to linefeed line endings for CVS files, allowing for better command-line compatibility? I saw thee recent :server: vs :ext: discussion, but since we use SSH on our project, MacCVSPro is already using :ext: in our CVS settings, leaving the linefeed-vs-return issue as our only command-line impediment.

        Sorry for the long message. Thought it might be better to put it all ion one lump.



Log in to post a comment.