Make directory appear as other directory - mount trickery?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
we operate within a corporate environment with many slightly weird constraints, to become effective in this environment we have created our own system for building and deploying software. The software typically works like this:
Download and build and install the software to the temporary location
$BUILD_ROOT/install.If all software packages is succesfully installed in step 1, "atomically" copy
$BUILD_ROOT/installto$PREFIXusingrsync.
This works quite well, but the problem is that some of the files created during the initial install step are not fully relocatable - and will contain contain the path $BUILD_ROOT/install.
I wondered if it were possible to make the $BUILD_ROOT/install directory (temporarily) appear as $PREFIX - i.e. that I could do something like:
mount-trick $PREFIX $BUILD_ROOT/install- configure and install software using
$PREFIX- but due to the mount-trick the files will actually go to$BUILD_ROOT/install. - cancel mount-trick
rsync $BUILD_ROOT/install $PREFIX
I sort of feel something like should be possible using things like bind mount, loop mount and/or chroot?
linux mount chroot
edited Feb 27 at 10:46
nwildner
13.2k14071
asked Feb 27 at 10:38
user422005
101
add a comment |Â
up vote
0
down vote
favorite
we operate within a corporate environment with many slightly weird constraints, to become effective in this environment we have created our own system for building and deploying software. The software typically works like this:
Download and build and install the software to the temporary location
$BUILD_ROOT/install.If all software packages is succesfully installed in step 1, "atomically" copy
$BUILD_ROOT/installto$PREFIXusingrsync.
This works quite well, but the problem is that some of the files created during the initial install step are not fully relocatable - and will contain contain the path $BUILD_ROOT/install.
I wondered if it were possible to make the $BUILD_ROOT/install directory (temporarily) appear as $PREFIX - i.e. that I could do something like:
mount-trick $PREFIX $BUILD_ROOT/install- configure and install software using
$PREFIX- but due to the mount-trick the files will actually go to$BUILD_ROOT/install. - cancel mount-trick
rsync $BUILD_ROOT/install $PREFIX
I sort of feel something like should be possible using things like bind mount, loop mount and/or chroot?
linux mount chroot
edited Feb 27 at 10:46
nwildner
13.2k14071
asked Feb 27 at 10:38
user422005
101
3
I think a better fix would be to store the target path instead of the build path... Is your build system entirely in-house, or is it based on something else? Most build systems can distinguish between build paths and installation paths (e.g. autoconf’s--prefixandDESTDIR).
– Stephen Kitt
Feb 27 at 10:43
This seems to be similar to what the OpenBSD port building system does, using a "fake install directory" before creating the package (which is later installed bypkg_add). I don't know much about the internals of that though.
– Kusalananda
Feb 27 at 10:49
Our build system is based on whatever native the package uses; i.e. configure+make, cmake, python setup, ... Have not (so far) had 100% succes with DESTDIR
– user422005
Feb 27 at 11:33
I’m not saying this means it’s easy, but Linux distributions manage to have 100% success, sometimes with patches admittedly. I do think it could be more useful in the long run to spend time getting build/install processes to work, than to spend time on a workaround. Each to his/her own though ;-).
– Stephen Kitt
Feb 27 at 17:53
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
we operate within a corporate environment with many slightly weird constraints, to become effective in this environment we have created our own system for building and deploying software. The software typically works like this:
Download and build and install the software to the temporary location
$BUILD_ROOT/install.If all software packages is succesfully installed in step 1, "atomically" copy
$BUILD_ROOT/installto$PREFIXusingrsync.
This works quite well, but the problem is that some of the files created during the initial install step are not fully relocatable - and will contain contain the path $BUILD_ROOT/install.
I wondered if it were possible to make the $BUILD_ROOT/install directory (temporarily) appear as $PREFIX - i.e. that I could do something like:
mount-trick $PREFIX $BUILD_ROOT/install- configure and install software using
$PREFIX- but due to the mount-trick the files will actually go to$BUILD_ROOT/install. - cancel mount-trick
rsync $BUILD_ROOT/install $PREFIX
I sort of feel something like should be possible using things like bind mount, loop mount and/or chroot?
linux mount chroot
edited Feb 27 at 10:46
nwildner
13.2k14071
asked Feb 27 at 10:38
user422005
101
we operate within a corporate environment with many slightly weird constraints, to become effective in this environment we have created our own system for building and deploying software. The software typically works like this:
Download and build and install the software to the temporary location
$BUILD_ROOT/install.If all software packages is succesfully installed in step 1, "atomically" copy
$BUILD_ROOT/installto$PREFIXusingrsync.
This works quite well, but the problem is that some of the files created during the initial install step are not fully relocatable - and will contain contain the path $BUILD_ROOT/install.
I wondered if it were possible to make the $BUILD_ROOT/install directory (temporarily) appear as $PREFIX - i.e. that I could do something like:
mount-trick $PREFIX $BUILD_ROOT/install- configure and install software using
$PREFIX- but due to the mount-trick the files will actually go to$BUILD_ROOT/install. - cancel mount-trick
rsync $BUILD_ROOT/install $PREFIX
I sort of feel something like should be possible using things like bind mount, loop mount and/or chroot?
linux mount chroot
edited Feb 27 at 10:46
nwildner
13.2k14071
asked Feb 27 at 10:38
user422005
101
edited Feb 27 at 10:46
nwildner
13.2k14071
edited Feb 27 at 10:46
nwildner
13.2k14071
edited Feb 27 at 10:46
nwildner
13.2k14071
13.2k14071
asked Feb 27 at 10:38
user422005
101
asked Feb 27 at 10:38
user422005
101
asked Feb 27 at 10:38
user422005
101
101
3
I think a better fix would be to store the target path instead of the build path... Is your build system entirely in-house, or is it based on something else? Most build systems can distinguish between build paths and installation paths (e.g. autoconf’s--prefixandDESTDIR).
– Stephen Kitt
Feb 27 at 10:43
This seems to be similar to what the OpenBSD port building system does, using a "fake install directory" before creating the package (which is later installed bypkg_add). I don't know much about the internals of that though.
– Kusalananda
Feb 27 at 10:49
Our build system is based on whatever native the package uses; i.e. configure+make, cmake, python setup, ... Have not (so far) had 100% succes with DESTDIR
– user422005
Feb 27 at 11:33
I’m not saying this means it’s easy, but Linux distributions manage to have 100% success, sometimes with patches admittedly. I do think it could be more useful in the long run to spend time getting build/install processes to work, than to spend time on a workaround. Each to his/her own though ;-).
– Stephen Kitt
Feb 27 at 17:53
add a comment |Â
3
I think a better fix would be to store the target path instead of the build path... Is your build system entirely in-house, or is it based on something else? Most build systems can distinguish between build paths and installation paths (e.g. autoconf’s--prefixandDESTDIR).
– Stephen Kitt
Feb 27 at 10:43
This seems to be similar to what the OpenBSD port building system does, using a "fake install directory" before creating the package (which is later installed bypkg_add). I don't know much about the internals of that though.
– Kusalananda
Feb 27 at 10:49
Our build system is based on whatever native the package uses; i.e. configure+make, cmake, python setup, ... Have not (so far) had 100% succes with DESTDIR
– user422005
Feb 27 at 11:33
I’m not saying this means it’s easy, but Linux distributions manage to have 100% success, sometimes with patches admittedly. I do think it could be more useful in the long run to spend time getting build/install processes to work, than to spend time on a workaround. Each to his/her own though ;-).
– Stephen Kitt
Feb 27 at 17:53
3
3
I think a better fix would be to store the target path instead of the build path... Is your build system entirely in-house, or is it based on something else? Most build systems can distinguish between build paths and installation paths (e.g. autoconf’s
--prefix and DESTDIR).– Stephen Kitt
Feb 27 at 10:43
I think a better fix would be to store the target path instead of the build path... Is your build system entirely in-house, or is it based on something else? Most build systems can distinguish between build paths and installation paths (e.g. autoconf’s
--prefix and DESTDIR).– Stephen Kitt
Feb 27 at 10:43
This seems to be similar to what the OpenBSD port building system does, using a "fake install directory" before creating the package (which is later installed by
pkg_add). I don't know much about the internals of that though.– Kusalananda
Feb 27 at 10:49
This seems to be similar to what the OpenBSD port building system does, using a "fake install directory" before creating the package (which is later installed by
pkg_add). I don't know much about the internals of that though.– Kusalananda
Feb 27 at 10:49
Our build system is based on whatever native the package uses; i.e. configure+make, cmake, python setup, ... Have not (so far) had 100% succes with DESTDIR
– user422005
Feb 27 at 11:33
Our build system is based on whatever native the package uses; i.e. configure+make, cmake, python setup, ... Have not (so far) had 100% succes with DESTDIR
– user422005
Feb 27 at 11:33
I’m not saying this means it’s easy, but Linux distributions manage to have 100% success, sometimes with patches admittedly. I do think it could be more useful in the long run to spend time getting build/install processes to work, than to spend time on a workaround. Each to his/her own though ;-).
– Stephen Kitt
Feb 27 at 17:53
I’m not saying this means it’s easy, but Linux distributions manage to have 100% success, sometimes with patches admittedly. I do think it could be more useful in the long run to spend time getting build/install processes to work, than to spend time on a workaround. Each to his/her own though ;-).
– Stephen Kitt
Feb 27 at 17:53
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
Mount bind should do the trick:
mount --bind /some/where /else/where
Borrowing from this great answer:
What is a bind mount?
A bind mount is an alternate view of a directory tree. Classically,
mounting creates a view of a storage device as a directory tree. A
bind mount instead takes an existing directory tree and replicates it
under a different point. The directories and files in the bind mount
are the same as the original. Any modification on one side is
immediately reflected on the other side, since the two views show the
same data.
answered Feb 27 at 10:44
nwildner
13.2k14071
Thank you; but as I understand it this way the content under the two directories will be the same. I want to access to the directorys /else/where - with naming as if it was /some/where - but it should be a truly distinct copy. If the build process (physically) targeting /else/where fails there should be no changes /some/where.
– user422005
Feb 27 at 10:47
And this way, how ismountsuposed to know that when you dismount the data inside$PREFIXneeds to remain on$BUILD_ROOT? When you unmount they will be totally different places(one with data, other without) so you canrsyncit...
– nwildner
Feb 27 at 10:53
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Mount bind should do the trick:
mount --bind /some/where /else/where
Borrowing from this great answer:
What is a bind mount?
A bind mount is an alternate view of a directory tree. Classically,
mounting creates a view of a storage device as a directory tree. A
bind mount instead takes an existing directory tree and replicates it
under a different point. The directories and files in the bind mount
are the same as the original. Any modification on one side is
immediately reflected on the other side, since the two views show the
same data.
answered Feb 27 at 10:44
nwildner
13.2k14071
Thank you; but as I understand it this way the content under the two directories will be the same. I want to access to the directorys /else/where - with naming as if it was /some/where - but it should be a truly distinct copy. If the build process (physically) targeting /else/where fails there should be no changes /some/where.
– user422005
Feb 27 at 10:47
And this way, how ismountsuposed to know that when you dismount the data inside$PREFIXneeds to remain on$BUILD_ROOT? When you unmount they will be totally different places(one with data, other without) so you canrsyncit...
– nwildner
Feb 27 at 10:53
add a comment |Â
up vote
0
down vote
Mount bind should do the trick:
mount --bind /some/where /else/where
Borrowing from this great answer:
What is a bind mount?
A bind mount is an alternate view of a directory tree. Classically,
mounting creates a view of a storage device as a directory tree. A
bind mount instead takes an existing directory tree and replicates it
under a different point. The directories and files in the bind mount
are the same as the original. Any modification on one side is
immediately reflected on the other side, since the two views show the
same data.
answered Feb 27 at 10:44
nwildner
13.2k14071
Thank you; but as I understand it this way the content under the two directories will be the same. I want to access to the directorys /else/where - with naming as if it was /some/where - but it should be a truly distinct copy. If the build process (physically) targeting /else/where fails there should be no changes /some/where.
– user422005
Feb 27 at 10:47
And this way, how ismountsuposed to know that when you dismount the data inside$PREFIXneeds to remain on$BUILD_ROOT? When you unmount they will be totally different places(one with data, other without) so you canrsyncit...
– nwildner
Feb 27 at 10:53
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Mount bind should do the trick:
mount --bind /some/where /else/where
Borrowing from this great answer:
What is a bind mount?
A bind mount is an alternate view of a directory tree. Classically,
mounting creates a view of a storage device as a directory tree. A
bind mount instead takes an existing directory tree and replicates it
under a different point. The directories and files in the bind mount
are the same as the original. Any modification on one side is
immediately reflected on the other side, since the two views show the
same data.
answered Feb 27 at 10:44
nwildner
13.2k14071
Mount bind should do the trick:
mount --bind /some/where /else/where
Borrowing from this great answer:
What is a bind mount?
A bind mount is an alternate view of a directory tree. Classically,
mounting creates a view of a storage device as a directory tree. A
bind mount instead takes an existing directory tree and replicates it
under a different point. The directories and files in the bind mount
are the same as the original. Any modification on one side is
immediately reflected on the other side, since the two views show the
same data.
answered Feb 27 at 10:44
nwildner
13.2k14071
answered Feb 27 at 10:44
nwildner
13.2k14071
answered Feb 27 at 10:44
nwildner
13.2k14071
answered Feb 27 at 10:44
nwildner
13.2k14071
13.2k14071
Thank you; but as I understand it this way the content under the two directories will be the same. I want to access to the directorys /else/where - with naming as if it was /some/where - but it should be a truly distinct copy. If the build process (physically) targeting /else/where fails there should be no changes /some/where.
– user422005
Feb 27 at 10:47
And this way, how ismountsuposed to know that when you dismount the data inside$PREFIXneeds to remain on$BUILD_ROOT? When you unmount they will be totally different places(one with data, other without) so you canrsyncit...
– nwildner
Feb 27 at 10:53
add a comment |Â
Thank you; but as I understand it this way the content under the two directories will be the same. I want to access to the directorys /else/where - with naming as if it was /some/where - but it should be a truly distinct copy. If the build process (physically) targeting /else/where fails there should be no changes /some/where.
– user422005
Feb 27 at 10:47
And this way, how ismountsuposed to know that when you dismount the data inside$PREFIXneeds to remain on$BUILD_ROOT? When you unmount they will be totally different places(one with data, other without) so you canrsyncit...
– nwildner
Feb 27 at 10:53
Thank you; but as I understand it this way the content under the two directories will be the same. I want to access to the directorys /else/where - with naming as if it was /some/where - but it should be a truly distinct copy. If the build process (physically) targeting /else/where fails there should be no changes /some/where.
– user422005
Feb 27 at 10:47
Thank you; but as I understand it this way the content under the two directories will be the same. I want to access to the directorys /else/where - with naming as if it was /some/where - but it should be a truly distinct copy. If the build process (physically) targeting /else/where fails there should be no changes /some/where.
– user422005
Feb 27 at 10:47
And this way, how is
mount suposed to know that when you dismount the data inside $PREFIX needs to remain on $BUILD_ROOT ? When you unmount they will be totally different places(one with data, other without) so you can rsync it...– nwildner
Feb 27 at 10:53
And this way, how is
mount suposed to know that when you dismount the data inside $PREFIX needs to remain on $BUILD_ROOT ? When you unmount they will be totally different places(one with data, other without) so you can rsync it...– nwildner
Feb 27 at 10:53
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f426904%2fmake-directory-appear-as-other-directory-mount-trickery%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
3
I think a better fix would be to store the target path instead of the build path... Is your build system entirely in-house, or is it based on something else? Most build systems can distinguish between build paths and installation paths (e.g. autoconf’s
--prefixandDESTDIR).– Stephen Kitt
Feb 27 at 10:43
This seems to be similar to what the OpenBSD port building system does, using a "fake install directory" before creating the package (which is later installed by
pkg_add). I don't know much about the internals of that though.– Kusalananda
Feb 27 at 10:49
Our build system is based on whatever native the package uses; i.e. configure+make, cmake, python setup, ... Have not (so far) had 100% succes with DESTDIR
– user422005
Feb 27 at 11:33
I’m not saying this means it’s easy, but Linux distributions manage to have 100% success, sometimes with patches admittedly. I do think it could be more useful in the long run to spend time getting build/install processes to work, than to spend time on a workaround. Each to his/her own though ;-).
– Stephen Kitt
Feb 27 at 17:53