Package file `rename` operation failing within `-A` #8

Closed
Kwpolska opened this Issue Sep 8, 2012 · 18 comments

Projects

None yet

3 participants

@Kwpolska
Contributor
Kwpolska commented Sep 8, 2012
[kwpolska@kwpolska-lin ~]% aura -A pkgbuilder
aura >>= You have to use `sudo` for that.

Sure, will do.

[root@kwpolska-lin kwpolska]# aura -A pkgbuilder
aura >>= You have to use `sudo` for that.

WTF? I am root, I can do EVERYTHING I want on this system!

You don’t always need it, and a more generic root message would be better (some people hate sudo for some reason or don’t have it installed).

[kwpolska@kwpolska-lin ~]% time sudo aura -A pkgbuilder
aura >>= Determining dependencies...
aura >>= Main AUR packages:
pkgbuilder

aura >>= Continue? [y/n] y
aura >>= Building `pkgbuilder`...
aura: pkgbuilder-2.1.4.3-1-any.pkg.tar.xz: rename: unsupported operation (Invalid cross-device link)
sudo aura -A pkgbuilder  2.12s user 0.76s system 17% cpu 16.089 total

Broken. With everything I tried. That “determining dependencies” stage was taking ages for me before. Also, showing makepkg output may be vital to your success. A default of y for the Continue prompt may be a good idea, too.

Imgur
If my shell was dumber (that isn’t the case with bash nor zsh), my shell would be green. And I do not like that.

[kwpolska@kwpolska-lin ~]% aura -Ah
aura >>= Conflicting flags given!

How am I supposed to know how to use aura, then? Read the manpage? It isn’t as easily discoverable as a help message.

@fosskers
Member
fosskers commented Sep 8, 2012

sudo -> Odd. Being should should allow you to use aura without sudo. I'll check this.
-A not working -> Aura moves built packages to the package cache by physically renaming the file. I don't know why that wouldn't be working on your system.
Deps -> Sometimes this is slow. It recursively searches for AUR deps using more PKGBUILD downloads with curl. Again, JSON should fix this. I imagine that's what yours does? I was jealous of it's dep determination speed.
help message -> This would be aura -h.

@fosskers
Member
fosskers commented Sep 9, 2012

I can't reproduce the root error.

I actually should make -Ah a thing, shouldn't I.

@AbigailBuccaneer

I'm getting precisely the same error when doing -A:

$ sudo aura -Ayu
:: Synchronising package databases...
 core is up to date
 extra is up to date
 community is up to date
aura >>= Fetching package information...
aura >>= Comparing package versions...
aura >>= Determining dependencies...
aura >>= Main AUR packages:
e2defrag-git
kindlegen
multimarkdown-git

aura >>= Continue? [y/n] y
aura >>= Building `e2defrag-git`...
aura: e2defrag-git-20120707-1-x86_64.pkg.tar.xz: rename: unsupported operation (Invalid cross-device link)
$
@fosskers
Member
fosskers commented Sep 9, 2012

How do the two of you have things mounted? Here's a line from the definition of renameFile which is the function at issue here:

A conformant implementation need not support renaming files in all situations 
(e.g. renaming across different physical devices), but the constraints must be documented.
@AbigailBuccaneer

Everything's on one physical device.

$ mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=970616k,nr_inodes=242654,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda8 on / type ext4 (rw,relatime,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=26,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
/dev/sda7 on /home type ext4 (rw,relatime,data=ordered)
/dev/sda6 on /boot type ext2 (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfs-fuse-daemon on /run/user/1000/gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
# fdisk -l

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc217c217

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63   312576704   156288321    7  HPFS/NTFS/exFAT
/dev/sda2       312576705   625142447   156282871+   5  Extended
/dev/sda5       312576768   318568949     2996091   82  Linux swap / Solaris
/dev/sda6   *   318569013   318761729       96358+  83  Linux
/dev/sda7       318761793   429835139    55536673+  83  Linux
/dev/sda8       429835203   586083329    78124063+  83  Linux
/dev/sda9       586083393   625142447    19529527+  83  Linux
@fosskers
Member
fosskers commented Sep 9, 2012

Ahhhh I see. Your / and /home are on different partitions. I imagine renameFile doesn't like that.
Try this: Go run aura in say... /etc.

@AbigailBuccaneer

/opt may be a better suggestion, but I'll go run it somewhere on the root partition and report back. :)

(Is renaming a file considered a different option than moving a file?)

@fosskers
Member
fosskers commented Sep 9, 2012

I could always try to copyFile, but that would take more time.

@AbigailBuccaneer

-Ayu works just fine on the root partition.

I'm no expert but you should be able to catch the error on renameFile, and fall back to copyFile then deleteFile.

This might be considered a bug with GHC's code.

@fosskers
Member
fosskers commented Sep 9, 2012

Just as I thought it might.

Yeah, I'd say this could be considered a bug... or at least an overlook. I wonder if ghc 7.6 fixes this?

@fosskers
Member

I'm considering making it so that all building occurs in temp folders in the package cache. That way they'll never be across different partitions.

@Kwpolska
Contributor

What?! So you say you are building stuff in cwd? Dumb. I do not allow anybody to create stuff when I am not aware of that. And what would happen if I tried to build PKGBUILDer in ~/git/? Would you remove my whole local copy of the repo?

@fosskers
Member

Don't get too excited here. I'm not being reckless; everything is built in temp files which are immediately removed from whatever directory they were created in. Nothing is left over after building (unlike `PKGBUILDer).This has never caused problems for me. You could build a package anywhere and the result would be the same.

@fosskers
Member

This should be fixed now. Please confirm.

@fosskers fosskers closed this Sep 11, 2012
@AbigailBuccaneer

Confirmed working for me.

@fosskers
Member

Thank you sir!

@Kwpolska
Contributor

Works on this side, too.

Nothing is left over after building (unlike PKGBUILDer).

I leave stuff over for two reasons: (1) if something fucked up in the build process, the user can go find the PKGBUILD in /tmp/ or CWD; (2) my old method of building packages was to do that in a directory that was publicly accessible.

@fosskers
Member

I like having clean builds / installs.

@nc6 nc6 added a commit to nc6/aura that referenced this issue Jun 28, 2013
@nc6 nc6 Fixes problem with renaming files across drives.
This was mentioned in issue #8, and is mostly fixed there. However,
it still occurs if part of the /var/cache/aura tree is mounted on
another drive.

This fix follows the normal behaviour unless it encounters an
unsupported operation (thrown when across drives), in which case
it resorts to copying the file instead.
d1ae4fb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment