Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Remove "p" flag to tar... #401

Merged
merged 1 commit into from

2 participants

@duckinator
Collaborator

...because, technically, untarring and keeping permissions in tact is impossible unless you're root or have the same UID, GID, etc...

@duckinator duckinator merged commit 85f56b9 into fasterthanlime:master
@nddrylliog
Collaborator

Don't permissions also include executable files, etc? Wouldn't we want to preserve that?

@duckinator
Collaborator
@duckinator
Collaborator

Wait, this is in the bootstrap, @nddrylliog... As in, it's just headers, C files, and a Makefile. So, as long as it's +rw there shouldn't be a problem, right?

EDIT: And I tested it on both ArchLinux and OpenBSD before merging, so it at least works.

@nddrylliog
Collaborator

I know it's in the bootstrap, I was just curious about tar's p option in general. I almost always use it when untarring stuff and I never had any problems with it.

Of course, if omitting 'p' still preserves executables then there's no reason to use it either.

@duckinator
Collaborator

The issue here is that it preserves the user/group info, and that is not consistent across systems that have different users -- or even 2+ of the same users set up in a different order! ie, if you set up two Arch systems: foo and bar. Foo has the users 'amos', 'moo' added in that order; bar has 'moo', 'amos' added in that order... The UIDs are switched, and the p option would no longer work: if you created a tarball on foo as amos, and tried to untar it on bar as amos...It'd try to use the same UID, and either throw errors or set the ownership to 'moo.'

The issue on OpenBSD is that the default group is the same as the username: the user nick on my OpenBSD VM has the groups nick and wheel. Note the lack of user.

I believe it tries both UID/GID and user/group names, but the effect is the same: OpenBSD does not, by default, have the users group that Linux assigns ownership to by default. This makes tar p worse than worthless, because it can't successfully untar it and retain permissions.

If you're using it for backups and the like, it's perfect. Distributions of any sort, not so much.

@nddrylliog
Collaborator

Okay, that makes sense.

@nddrylliog
Collaborator

That would be me :D I just generally try to cram as many tar options as I can. Probably a bad practice.

Just curious, did you actually get problems with that?

Collaborator

Yes -- that's how I noticed it! iirc it extracted stuff you couldn't access on every BSD system, as well as any Linux system where you weren't logged in as the first non-root user (UID 1000).

Collaborator

Ha! That actually makes a lot of sense.

Also - and on an unrelated note - would you accept to do some Win32 testing/debugging with me? Feeling a bit alone on that platform, and it's a higher priority than *BSD imho :)

Collaborator

I would if I had a working Win32 setup -- don't have an XP key, and can't get Win7 or Win8 to boot in VirtualBox since switching to Mint. *glares at VirtualBox...or Mint...or something*

I'll take a whack at another Win7 install later (I think my Win8 beta/whatever key expired), and try to figure out what the hell it's doing. If it works I'll help you out, if not, sorry. :P

Does #469 have everything I need to figure out what needs testing/debugging, in case you're not around if/when I finally convince something Win32 to boot?

Collaborator

I'd advise Win7 in VirtualBox + mingw as a basic setup :) And yes #469 is pretty self-explanatory. It just.. fails hard on make rescue, that is all.

rock-0.9.3 still compiles well though! With the usual work-arounds (TimeT and -nolibcache, stuff like that).

Imho we should really get 0.9.4 to compile everywhere and then release it. (poke @shamanas here too. :D)

Collaborator

Alright. I'll try a Win7 install later tonight and try mingw if I can get the thing to boot.

Yes, we definitely need to get 0.9.4 compiling everywhere -- and if we can't get rid of all of the workarounds, we should make them automatically enabled on Win32 so it might actually be easily usable. (with a large, 5+ line comment explaining how much of a horrifying hack it is, and how many kittens did their best lemming imitation to get away from it)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
Showing with 2 additions and 2 deletions.
  1. +2 −2 Makefile
View
4 Makefile
@@ -98,7 +98,7 @@ rescue:
rm -rf build/
# Note: ./utils/downloader tries curl, ftp, and then wget.
# GNU ftp will _not_ work: it does not accept a url as an argument.
- ./utils/downloader.sh http://www.fileville.net/ooc/bootstrap.tar.bz2 | tar xjvmpf - 1>/dev/null
+ ./utils/downloader.sh http://www.fileville.net/ooc/bootstrap.tar.bz2 | tar xjvmf - 1>/dev/null
if [ ! -e build ]; then cp -rfv rock-*/build ./; fi
$(MAKE) clean bootstrap
@@ -111,7 +111,7 @@ ifeq ($(VERSION),)
@echo "You must specify VERSION. Generates rock-VERSION-bootstrap-only.tar.bz2"
else
$(MAKE) prepare_bootstrap
- tar cjvfmp rock-${VERSION}-bootstrap-only.tar.bz2 build
+ tar cjvfm rock-${VERSION}-bootstrap-only.tar.bz2 build
endif
# Clean all temporary files that may make a build fail
Something went wrong with that request. Please try again.