Attempting to extract xenocara.tar.gz while avoiding root proviliges as described here https://www.openbsd.org/faq/faq5.html#wsrc, I ran into an error, shown below:
0 thinkpad$ pwd /usr/xenocara 0 thinkpad$ ls -a . .. 0 thinkpad$ tar xzf /home/rob/openbsd_files/7.0/xenocara.tar.gz tar: Access/modification time set failed on: .: Operation not permitted 1 thinkpad$ ls -a . 3RDPARTY Makefile data doc font share .. CVS README dist driver lib util .gitignore MODULES app distrib etc proto xserver 0 thinkpad$ cd .. 0 thinkpad$ ls -ld xenocara drwxrwxr-x 16 root wsrc 512 Jan 12 21:43 xenocara 0 thinkpad$ id uid=1001(rob) gid=1001 groups=1001, 0(wheel), 9(wsrc) 0 thinkpad$ Running ktrace on tar shows that tar is trying to set the mtime of ., which corresponds to /usr/xenocara, with the function futimens, which fails. According to the man page for futimens, if the times argument is non-NULL, which is the case here, then the caller must be the owner of the file or the superuser. For an unprivileged user, this is not the case, as, although /usr/xenocara has group wsrc, it has owner root. Running tar tzf xenocara.tar.gz shows an entry for . which seems to be causing this problem. If you instead run tar xzf xenocara.tar.gz -s '/^\.$//' to omit only the . entry when extracting, there is no more error. There is a side effect to adding this -s option, which is that /usr/xenocara's mtime gets updated to the time the tarball extraction took place, as opposed to the time that was recorded for . in the tarball. I don't know whether updating /usr/xenocara to the mtime that was recorded in the tarball was intentional behavior or not. If updating the mtime of /usr/xenocara was not intentional behavior, it would seem to me that the fix for this problem would be to not include the . directory when making the tarball xenocara.tar.gz. I was unable to locate any code that was responsible for creating xenocara.tar.gz so I have not included a diff. If anybody could tell me where that code is then that would be appreciated. As another issue, extracting ports.tar.gz as a non-privileged user in /usr, as described in the document whose address is given above, results in failure due to lack of permission, as a normal user does not have access to create the /usr/ports directory. I am running a snapshot of OpenBSD 7.0 that is only a few days old.
