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

Perhaps the -U option would help during extraction? Since it's not allowing you to overwrite, maybe unlinking the files first would do the trick.
-U (x mode only) Unlink files before creating them. Without + this option, tar overwrites existing files, which preserves ex +isting hardlinks. With this option, existing hardlinks will be +broken, as will any symlink that would affect the location of an + extracted file.

Replies are listed 'Best First'.
Re^2: [OT] Tar file with non-identical duplicate files and no paths?(A solution)
by BrowserUk (Patriarch) on Sep 13, 2008 at 09:36 UTC

    -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.
      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

      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.

        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.