Faking a directory path without the full path existing

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












I'm working with a build system that relies on absolute paths to reference source files etc. When I want to test building with different toolchains, I mount the src directory in VMs or chroots. The problem is that the path to my src directory on my host machine is very complex -- lets say /a/b/c/d/src -- and it has to match the mounted path.



I want to be able to mount my src directory in somewhere like /mnt/src, but I always end up needing to create a symlink /a/b/c/d/src to /mnt/src, or just have the mountpoint at /a/b/c/d/src directly.



It feels dirty to have /a/b/c/d in the filesystem, and in general you might not even have permissions to create files in /a/b/c/d (or any of the parent directories). Is there any way to fake this path to appease my build system?







share|improve this question
























    up vote
    2
    down vote

    favorite












    I'm working with a build system that relies on absolute paths to reference source files etc. When I want to test building with different toolchains, I mount the src directory in VMs or chroots. The problem is that the path to my src directory on my host machine is very complex -- lets say /a/b/c/d/src -- and it has to match the mounted path.



    I want to be able to mount my src directory in somewhere like /mnt/src, but I always end up needing to create a symlink /a/b/c/d/src to /mnt/src, or just have the mountpoint at /a/b/c/d/src directly.



    It feels dirty to have /a/b/c/d in the filesystem, and in general you might not even have permissions to create files in /a/b/c/d (or any of the parent directories). Is there any way to fake this path to appease my build system?







    share|improve this question






















      up vote
      2
      down vote

      favorite









      up vote
      2
      down vote

      favorite











      I'm working with a build system that relies on absolute paths to reference source files etc. When I want to test building with different toolchains, I mount the src directory in VMs or chroots. The problem is that the path to my src directory on my host machine is very complex -- lets say /a/b/c/d/src -- and it has to match the mounted path.



      I want to be able to mount my src directory in somewhere like /mnt/src, but I always end up needing to create a symlink /a/b/c/d/src to /mnt/src, or just have the mountpoint at /a/b/c/d/src directly.



      It feels dirty to have /a/b/c/d in the filesystem, and in general you might not even have permissions to create files in /a/b/c/d (or any of the parent directories). Is there any way to fake this path to appease my build system?







      share|improve this question












      I'm working with a build system that relies on absolute paths to reference source files etc. When I want to test building with different toolchains, I mount the src directory in VMs or chroots. The problem is that the path to my src directory on my host machine is very complex -- lets say /a/b/c/d/src -- and it has to match the mounted path.



      I want to be able to mount my src directory in somewhere like /mnt/src, but I always end up needing to create a symlink /a/b/c/d/src to /mnt/src, or just have the mountpoint at /a/b/c/d/src directly.



      It feels dirty to have /a/b/c/d in the filesystem, and in general you might not even have permissions to create files in /a/b/c/d (or any of the parent directories). Is there any way to fake this path to appease my build system?









      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 19 '17 at 20:52









      tomKPZ

      1134




      1134




















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          2
          down vote



          accepted










          The best solution would be to teach that build system that source paths and installation paths are not the same thing, but I'll assume you can't do that.



          The most straightforward method would be to arrange for the source path to be something that can be easily reproduced, such as /var/tmp/mybuild. If the build system isn't too obnoxious, making this a symbolic link to where the files are located should be enough. If the build system insists on canonicalizing symbolic links, you should be able to fool it by using a bind mount instead. With bindfs, you don't need root privileges, you only need to have write permission on the location where you want to make the files appear.



          If you can't act on the source system, an alternative approach is to preload a dynamic library that redirect certain file accesses. This assumes that all the executables that will be running are linked dynamically. The code in the linked example demonstrates how to do it from a specific file; it can be tweaked to redirect all the files whose path starts with a certain prefix. Replace



          if (!strcmp(path, FROM)) 
          path = TO;

          …
          return ret;


          by something like (untested)



          char *other_path = NULL;
          if (!strncmp(path, FROM, strlen(FROM)))
          other_path = malloc(strlen(path) - strlen(FROM) + strlen(TO) + 1);
          if (other_path == NULL) return -ENOENT; // return NULL in fopen
          memcpy(other_path, TO, strlen(TO));
          memcpy(other_path + strlen(TO), path + strlen(FROM), strlen(path) - strlen(FROM) + 1);
          path = other_path;

          …
          free(other_path);
          return ret;





          share|improve this answer



























            up vote
            0
            down vote













            If your objective is to avoid polluting "the host" with residue from test builds, then building inside a firejail with persistent overlay should be a good option. By that approach, it would build, and maybe install, as if for real, but the files end up in an overlay rather than polluting "the real" file system.



            There is the drawback that you'll need to locate test build results within the overlay, but at the same time this has the possible advantage of preserving successive test build results, e.g., for comparing them, or whatever other later forensic you might need to do.






            share|improve this answer




















              Your Answer







              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "106"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              convertImagesToLinks: false,
              noModals: false,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );













               

              draft saved


              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405654%2ffaking-a-directory-path-without-the-full-path-existing%23new-answer', 'question_page');

              );

              Post as a guest






























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes








              up vote
              2
              down vote



              accepted










              The best solution would be to teach that build system that source paths and installation paths are not the same thing, but I'll assume you can't do that.



              The most straightforward method would be to arrange for the source path to be something that can be easily reproduced, such as /var/tmp/mybuild. If the build system isn't too obnoxious, making this a symbolic link to where the files are located should be enough. If the build system insists on canonicalizing symbolic links, you should be able to fool it by using a bind mount instead. With bindfs, you don't need root privileges, you only need to have write permission on the location where you want to make the files appear.



              If you can't act on the source system, an alternative approach is to preload a dynamic library that redirect certain file accesses. This assumes that all the executables that will be running are linked dynamically. The code in the linked example demonstrates how to do it from a specific file; it can be tweaked to redirect all the files whose path starts with a certain prefix. Replace



              if (!strcmp(path, FROM)) 
              path = TO;

              …
              return ret;


              by something like (untested)



              char *other_path = NULL;
              if (!strncmp(path, FROM, strlen(FROM)))
              other_path = malloc(strlen(path) - strlen(FROM) + strlen(TO) + 1);
              if (other_path == NULL) return -ENOENT; // return NULL in fopen
              memcpy(other_path, TO, strlen(TO));
              memcpy(other_path + strlen(TO), path + strlen(FROM), strlen(path) - strlen(FROM) + 1);
              path = other_path;

              …
              free(other_path);
              return ret;





              share|improve this answer
























                up vote
                2
                down vote



                accepted










                The best solution would be to teach that build system that source paths and installation paths are not the same thing, but I'll assume you can't do that.



                The most straightforward method would be to arrange for the source path to be something that can be easily reproduced, such as /var/tmp/mybuild. If the build system isn't too obnoxious, making this a symbolic link to where the files are located should be enough. If the build system insists on canonicalizing symbolic links, you should be able to fool it by using a bind mount instead. With bindfs, you don't need root privileges, you only need to have write permission on the location where you want to make the files appear.



                If you can't act on the source system, an alternative approach is to preload a dynamic library that redirect certain file accesses. This assumes that all the executables that will be running are linked dynamically. The code in the linked example demonstrates how to do it from a specific file; it can be tweaked to redirect all the files whose path starts with a certain prefix. Replace



                if (!strcmp(path, FROM)) 
                path = TO;

                …
                return ret;


                by something like (untested)



                char *other_path = NULL;
                if (!strncmp(path, FROM, strlen(FROM)))
                other_path = malloc(strlen(path) - strlen(FROM) + strlen(TO) + 1);
                if (other_path == NULL) return -ENOENT; // return NULL in fopen
                memcpy(other_path, TO, strlen(TO));
                memcpy(other_path + strlen(TO), path + strlen(FROM), strlen(path) - strlen(FROM) + 1);
                path = other_path;

                …
                free(other_path);
                return ret;





                share|improve this answer






















                  up vote
                  2
                  down vote



                  accepted







                  up vote
                  2
                  down vote



                  accepted






                  The best solution would be to teach that build system that source paths and installation paths are not the same thing, but I'll assume you can't do that.



                  The most straightforward method would be to arrange for the source path to be something that can be easily reproduced, such as /var/tmp/mybuild. If the build system isn't too obnoxious, making this a symbolic link to where the files are located should be enough. If the build system insists on canonicalizing symbolic links, you should be able to fool it by using a bind mount instead. With bindfs, you don't need root privileges, you only need to have write permission on the location where you want to make the files appear.



                  If you can't act on the source system, an alternative approach is to preload a dynamic library that redirect certain file accesses. This assumes that all the executables that will be running are linked dynamically. The code in the linked example demonstrates how to do it from a specific file; it can be tweaked to redirect all the files whose path starts with a certain prefix. Replace



                  if (!strcmp(path, FROM)) 
                  path = TO;

                  …
                  return ret;


                  by something like (untested)



                  char *other_path = NULL;
                  if (!strncmp(path, FROM, strlen(FROM)))
                  other_path = malloc(strlen(path) - strlen(FROM) + strlen(TO) + 1);
                  if (other_path == NULL) return -ENOENT; // return NULL in fopen
                  memcpy(other_path, TO, strlen(TO));
                  memcpy(other_path + strlen(TO), path + strlen(FROM), strlen(path) - strlen(FROM) + 1);
                  path = other_path;

                  …
                  free(other_path);
                  return ret;





                  share|improve this answer












                  The best solution would be to teach that build system that source paths and installation paths are not the same thing, but I'll assume you can't do that.



                  The most straightforward method would be to arrange for the source path to be something that can be easily reproduced, such as /var/tmp/mybuild. If the build system isn't too obnoxious, making this a symbolic link to where the files are located should be enough. If the build system insists on canonicalizing symbolic links, you should be able to fool it by using a bind mount instead. With bindfs, you don't need root privileges, you only need to have write permission on the location where you want to make the files appear.



                  If you can't act on the source system, an alternative approach is to preload a dynamic library that redirect certain file accesses. This assumes that all the executables that will be running are linked dynamically. The code in the linked example demonstrates how to do it from a specific file; it can be tweaked to redirect all the files whose path starts with a certain prefix. Replace



                  if (!strcmp(path, FROM)) 
                  path = TO;

                  …
                  return ret;


                  by something like (untested)



                  char *other_path = NULL;
                  if (!strncmp(path, FROM, strlen(FROM)))
                  other_path = malloc(strlen(path) - strlen(FROM) + strlen(TO) + 1);
                  if (other_path == NULL) return -ENOENT; // return NULL in fopen
                  memcpy(other_path, TO, strlen(TO));
                  memcpy(other_path + strlen(TO), path + strlen(FROM), strlen(path) - strlen(FROM) + 1);
                  path = other_path;

                  …
                  free(other_path);
                  return ret;






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 19 '17 at 22:25









                  Gilles

                  507k12010031531




                  507k12010031531






















                      up vote
                      0
                      down vote













                      If your objective is to avoid polluting "the host" with residue from test builds, then building inside a firejail with persistent overlay should be a good option. By that approach, it would build, and maybe install, as if for real, but the files end up in an overlay rather than polluting "the real" file system.



                      There is the drawback that you'll need to locate test build results within the overlay, but at the same time this has the possible advantage of preserving successive test build results, e.g., for comparing them, or whatever other later forensic you might need to do.






                      share|improve this answer
























                        up vote
                        0
                        down vote













                        If your objective is to avoid polluting "the host" with residue from test builds, then building inside a firejail with persistent overlay should be a good option. By that approach, it would build, and maybe install, as if for real, but the files end up in an overlay rather than polluting "the real" file system.



                        There is the drawback that you'll need to locate test build results within the overlay, but at the same time this has the possible advantage of preserving successive test build results, e.g., for comparing them, or whatever other later forensic you might need to do.






                        share|improve this answer






















                          up vote
                          0
                          down vote










                          up vote
                          0
                          down vote









                          If your objective is to avoid polluting "the host" with residue from test builds, then building inside a firejail with persistent overlay should be a good option. By that approach, it would build, and maybe install, as if for real, but the files end up in an overlay rather than polluting "the real" file system.



                          There is the drawback that you'll need to locate test build results within the overlay, but at the same time this has the possible advantage of preserving successive test build results, e.g., for comparing them, or whatever other later forensic you might need to do.






                          share|improve this answer












                          If your objective is to avoid polluting "the host" with residue from test builds, then building inside a firejail with persistent overlay should be a good option. By that approach, it would build, and maybe install, as if for real, but the files end up in an overlay rather than polluting "the real" file system.



                          There is the drawback that you'll need to locate test build results within the overlay, but at the same time this has the possible advantage of preserving successive test build results, e.g., for comparing them, or whatever other later forensic you might need to do.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Nov 19 '17 at 21:26









                          Ralph Rönnquist

                          2,43738




                          2,43738



























                               

                              draft saved


                              draft discarded















































                               


                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function ()
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405654%2ffaking-a-directory-path-without-the-full-path-existing%23new-answer', 'question_page');

                              );

                              Post as a guest













































































                              Popular posts from this blog

                              How to check contact read email or not when send email to Individual?

                              Displaying single band from multi-band raster using QGIS

                              How many registers does an x86_64 CPU actually have?