Re: Info-ZIP UnZip on VMS v. directory attributes: Time for a change?

From: "AEF" <spamsink2001@xxxxxxxxx>

Well, the only potential problem I can think of offhand is that if the
directories were originally set to RE for all four categories, then
that could interfere with restoring files to said directories as W
access is needed to add files to a directory. I've seen this very
problem happen with BACKUP back in the 1980s (during a non-image
restore). Certainly if the protections are somehow set after all files
are in place I don't see a problem. Restoring with BYPASS priv would
also obviate the problem.

As I said, "the directory attributes are handled by a post-processing
step".

I don't think that I'd want to use an UnZip which had BYPASS.

In the tentative code, if you say "-X" but you lack the privilege
needed to set the ownership for a file or a directory, you (usually) get
a %SYSTEM-F-NOPRIV complaint, as might be expected. Generally, I'd say,
"-X" is useful only for a privileged user.


From: David J Dachtera <djesys.no@xxxxxxxxxxxxxxxx>

My opinion is that if the directory is actually stored in the archive, then
restore using the saved attributes. If the directory is created because it is
needed and does not exist when restoring from an archive, then it should be
created on the fly and the usual defaults should apply.

The directory itself is not stored, but some of its attributes are.
Currently, all directories are created as needed, using a simple
mkdir(), so you get the usual default permissions. This sounds
harmless, but it's different from all other files, which have their
permissions set to match their original permissions. It's also
different from the UnZip behavior on all other operating systems, where
directory permissions are adjusted match their original permissions.

Strictly speaking, all the normal files are also created because
they're needed, and they get their permissions restored.


The tentative code seems to be fairly happy (so far), but there seems
to be one quirk: If a non-privileged user does "unzip -X" and restores
a directory which he did not own, the attempt to set the ownership fails
with %SYSTEM-F-NOPRIV, which is ok with me. However, on a directory
which he _did_ own, the attempt to set the ownership (to what it already
is, I believe) fails with %SYSTEM-F-BADPARAM. I consider this to be a
harmless NOP, and don't see why it should fail this way. Anyone know
why?

Oh, and for the moment, "-X" requests restoration of directory
ownership, and "-XX" _adds_ restoration of directory date-times. I'm
guessing that no one will actually want that last feature, as no one
seems to have missed it enough to complain about it since the beginning
of time. (Of course, only one person seems to have noticed the
directory ownership problem in the same time interval.)

------------------------------------------------------------------------

Steven M. Schweda sms@antinode-org
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
.

Relevant Pages

  • Re: Disaster Recovery Scenario Help
    ... Right...I understand the concept of the SID... ... assign them permissions, then what would be affected by the SID change other ... >>> promote the DR servers into DCs? ... In that case restoring DCs ...
    (microsoft.public.windows.server.active_directory)
  • Re: Preventing users from opening onther users mailbox in outlook
    ... Simply restoring the information store itself will not modify the ... The permissions on those objects are stored in Active ... Go into a user account properties, go to the Exchange Advanced tab (may need ... With Full Mailbox Access? ...
    (microsoft.public.exchange.admin)
  • Re: loss of permissions
    ... When you restore your database, you lose the permissions that had been ... Your problem is that your database's permissions (users, roles, and grants) ... are not the same as the database that you are restoring from. ...
    (microsoft.public.sqlserver.dts)
  • Re: Password for CurrentUser()
    ... restored mdw. ... protect from restoring old backups -unless one did some sort of ... But my point was that instead of applying permissions to groups, ... Even if a user restores an old mdw and uses their old ...
    (microsoft.public.access.security)
  • Taking Ownership problem
    ... I took ownership of the folder and its ... Although she had assured me she was out of the folder, ... I go into permissions, it tells me that I do not have access but that I can ... I tried restoring from backup but the ...
    (microsoft.public.security)