It is just a warning, you can ignore it. I am not going to change my processes to ship a tar file without "."
Rob Whitlock <rwhitloc...@gmail.com> wrote: > 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.
