in reply to Re: [OT] Tar file with non-identical duplicate files and no paths?
in thread [OT] Tar file with non-identical duplicate files and no paths?

-U didn't work because the first one out has the readonly attribute set, so it can't be unlinked. However, whist looking for an option to discard attributes (which doesn't appear to exist), I noticed -w. By saying no to the first chance to extract the duplicated files, it allows me to get the second ones. Thanks :)

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^2: [OT] Tar file with non-identical duplicate files and no paths?(A solution)

Replies are listed 'Best First'.
Re^3: [OT] Tar file with non-identical duplicate files and no paths?(A solution)
by repellent (Priest) on Sep 13, 2008 at 21:35 UTC
    D'oh! I missed the -w option. Good thing you found it :)

      -U didn't work because the first one out has the readonly attribute set, so it can't be unlinked.

    OK, something is amiss here. I sometimes get confused about this issue, which is why I made the following notes for myself:
    # a file and its filename are different!
# permissions are on files, not filenames => control of filenames is l
+eft up to the directory
# directories contain filenames (not files!), that themselves refer to
+ files

  file      readable   # may examine file contents
  file      writable   # may alter   file contents
  file      xecutable  # may run     file contents

  directory readable   # may examine directory contents (list filename
+s in directory)
  directory writable   # may alter   directory contents (remove or ren
+ame filenames)
  directory xecutable  # may use     directory as component in pathnam
+es or chdir to that directory

# a read-only file is only protecting data (not its filename) from bei
+ng changed

    [download]

    As I understand it: unlinking a file is not determined by the permissions set on the file itself. It is the permissions set on the directory where the file resides in that determines whether the "filename" can be unlinked from the directory aforementioned.
[reply]
[d/l]
[select]

      At this point, most of what you've written goes over my head (//////........there it goes :). I'm working on Win32 with a native port of GNU tar. Files in perl module tar.gzs often come out with their (win23) readonly attribute set. I've no idea if this is a misbegotten attempt to map *nix permissions to Win32 attributes by the tar port I'm using, or some other combination of factors. I know it bugs the heck out of me, but I don't even know where to point the finger.

      I also tried extracting the relevant files using WinZip per some of the other posts, but it seems to get really confused by the idea of an archive containing two files with the same name and no path to differentiate them. Admittedly it's a really ancient version, but I rarely use it and the newer versions are about 5 times the size and seem to want to install hooks all over the damn place.

      It is a weird way to build an archive, flat with duplicates. I'm a bit surprised that tar allows it, but ... I got the files I needed, so the rest is just something to ponder late at night :)

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        You could peep into the DBD-Pg-2.10.0-Perl5.8.tar binary and string search for Pg.pm. That way, you can really find out if there are actually paths associated with the duplicates.

        I'm guessing that tar you're using is confused about how to map paths over from *nix. This manifests as extracting "flat with duplicates".

        Yeah, best left to ponder later :)
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom