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

Re: [wpmac] Odd WP 3.5e behavior to Xserve

Expand Messages
  • russellhwalker
    ... Thanks, everyone, for the suggestions. I m sure that all of you noticed a typo in my original post - the retired ASIP server was ASIP 6.3, not 4.3 (from
    Message 1 of 8 , Sep 12, 2005
    • 0 Attachment
      --- In wordperfectmac@yahoogroups.com, "John Rethorst"
      <jrethorst@y...> wrote:
      > --- In wordperfectmac@yahoogroups.com, "Phillip Jones, C.E.T."
      > <pjones1@k...> wrote:
      > > This is going to be a pain to do if you have gazillions of files.
      > >
      > > But if he has a few do the following.
      > >
      > > click on each file one at a time and choose GetInfo. In OSX
      > > set to read only.
      >
      > Good idea (an Applescript can automate it). I'm guessing that
      > whatever this server software is up to, it might not respond
      > to the OSX read/write permissions the same as it does to the
      > locked status.

      Thanks, everyone, for the suggestions. I'm sure that all of you
      noticed a typo in my original post - the retired ASIP server was ASIP
      6.3, not 4.3 (from which we upgraded about ten or so years ago), and I
      was tired when typing the original post. Sorry for the confusion.

      Regarding the suggestion to change everything to Stationery, sorry but
      that's a non-option.

      Regarding the gazillions of files, yes, we have well over 500,000
      files, but they are at most three folder levels deep on the share
      (e.g., "Clients A-F", client name, client matter, then the file), and,
      as I indicated in my original post, I was able to work around the
      problem for the time being by, from terminal as root, chmod */* ugo-w;
      chmod */*/* ugo-w and also by removing this attorney from the server
      admin group. No AppleScript was necessary.

      As I indicated, this attorney is currently running Mac OS 9.1, so, of
      course, there are other Mac OS 9 programs that he runs on the
      server-located files (including, kicking and screaming, Microsoft
      Word). None of the others exhibit this odd behavior of unlocking
      locked files and changing the modification date/time simply upon open
      with no save attempt; only WordPerfect. Now some programs will
      indicate that the file is locked and ask if you want the file to
      become unlocked, and will then do so. But it seems odd that a program
      would unlock the file on its own and change the modification date/time
      without asking.

      Anyway, I've worked around the problem by locking down the permissions
      and it looks like there may be no better solution. The only downside
      of this workaround is that currently-active files in the process of
      revision cannot be written by anyone, and people have to go through an
      "open/save as" step (to read then write the now-unwritable file), then
      delete the older file and rename the "saved as" file.

      Thanks. I'm surprised that this hasn't been seen before. I'll now
      tackle getting WP to run under Classic on Mac OS 10.4.2 so that we can
      retire the Mac OS 9.1 machine. It's possible that the problem will
      still exist under Classic. I'll report results under Classic FYI as
      soon as I get that working.

      Regards,

      Russ
    • russellhwalker
      ... The evidence indicates otherwise if the Unix permissions allow but the file is locked. I ve got an existence proof with over 500,000 instances. This may
      Message 2 of 8 , Sep 12, 2005
      • 0 Attachment
        --- In wordperfectmac@yahoogroups.com, "John Rethorst"
        <jrethorst@y...> wrote:
        > Unlocking the file on open and
        > updating its modification date are things WP can't do on its own.

        The evidence indicates otherwise if the Unix permissions allow but the
        file is locked. I've got an existence proof with over 500,000 instances.

        This may be some artifact of a massive transfer from an ASIP 6.3
        share, which is why I gave the history. Anyway, if the Unix
        permissions don't permit writing the file, then WordPerfect doesn't
        seem to be able to unlock the file and change the modify date/time
        simply upon opening the file.

        Russ
      • Phillip Jones, C.E.T.
        Everyone has to realize that WP Mac is an OS9 program that runs through a emulator when called in OSX. In OS9 go to getInfo and tick the check box for
        Message 3 of 8 , Sep 12, 2005
        • 0 Attachment
          Everyone has to realize that WP Mac is an OS9 program that runs through
          a emulator when called in OSX. In OS9 go to getInfo and tick the check
          box for stationery which means it will open a "copy" of the file. and
          not open the original file.

          russellhwalker wrote:
          > --- In wordperfectmac@yahoogroups.com, "John Rethorst"
          > <jrethorst@y...> wrote:
          >> Unlocking the file on open and updating its modification date are
          >> things WP can't do on its own.
          >
          > The evidence indicates otherwise if the Unix permissions allow but
          > the file is locked. I've got an existence proof with over 500,000
          > instances.
          >
          > This may be some artifact of a massive transfer from an ASIP 6.3
          > share, which is why I gave the history. Anyway, if the Unix
          > permissions don't permit writing the file, then WordPerfect doesn't
          > seem to be able to unlock the file and change the modify date/time
          > simply upon opening the file.
          >
          > Russ

          ------------------------------------------------------------------------
          Phillip M. Jones, CET |LIFE MEMBER: VPEA ETA-I, NESDA, ISCET, Sterling
          616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
          Martinsville Va 24112 |pjones@..., ICQ11269732, AIM pjonescet
          ------------------------------------------------------------------------
        Your message has been successfully submitted and would be delivered to recipients shortly.