> > 2. Get Mercurial and run tests in VM > hg clone http://selenic.com/hg > cd hg/contrib/vagrant > vagrant up > vagrant ssh -c ./run-tests.sh > > Vagrant mounts current folder as /vagrant inside VM, so when I cd to this > folder and try to create symlink, I get a nasty error: > > vagrant ssh > > $ cd /vagrant > $ ln config.yml config.yml2 > ln: failed to create hard link `config.yml2' => `config.yml': > Operation not permitted > $ ln -s config.yml config.yml2 > ln: failed to create symbolic link `config.yml2': Protocol error > $ python -c "import os; os.symlink('config.yml', 'config.yml2')" > Traceback (most recent call last): > File "<string>", line 1, in <module> > OSError: [Errno 71] Protocol error >
I've never used vagrant before, but it was fairly intuitive with your example. 1. run-tests.sh is still executing after 30min+ and there are some errors, but nothing I can see related to symlinks. 2. I was able to create symlinks inside the "/vagrant" directory Based on this example, I don't think your use case makes sense. In order for the SCons Copy code to fail on "os.symlink", Copy must be attempting to copy a symlink: > ls -l > lrwx------ item -> item.txt > -rwx------ item.txt > cat SConstruct > Copy( 'item', 'item_link', True ) # default is True anyway > Copy( 'item', 'item_file', False ) # default is True anyway > scons Copy( item, item_link ) Copy( item, item_file ) > ls -l > lrwx------ item -> item.txt > -rwx------ item.txt > lrwx------ item_link -> item.txt > -rwx------ item_file > echo "item.txt & item_file inode count is 1" Copy does not try to create a symlink from a "real" file: > ls -l > -rwx------ item.txt > cat SConstruct > Copy( 'item.txt', 'item_copy', True ) # default is True anyway > scons Copy( item.txt, item_copy ) > ls -l > -rwx------ item.txt > -rwx------ item_copy > echo "item.txt & item_copy inode count is 1" Since the filesystem in the example does not support symlinks (I assume), then SCons will not be trying to copy a symlink anyway. Maybe it was just a bad example? You could still have this issue if you are copying a symlink from a filesystem that supports it to one that doesn't. V/R, William On Tue, Jul 29, 2014 at 1:13 PM, anatoly techtonik <techto...@gmail.com> wrote: > On Tue, Jul 29, 2014 at 2:39 AM, William Blevins <wblevins...@gmail.com> > wrote: > >> > I think it is reasonable for SCons to support symlinks on systems that > >> > support symlinks. > >> It is not the matter of supporting, it is the matter of using them by > >> default. > >> You need to check FS support - not operating systems support to make > >> it work without pain by default. There are many cases where people use > >> virtual machines to build stuff on different systems and source > directory > >> often gets shared with network protocol that doesn't support symlinking > >> even if os supports it. > > > > If someone is creating symlinks for code intended to be placed in a > shared > > directory with a Windows O/S, shame on them? Does this happen in software > > you maintain or is this hypothetical? > > I am taking about directories shared with Virtual Machines. I don't have > example with SCons at the moment, but these are two real world examples > wit Vagrant for you to try. It won't take a lot of time. > > 1. Get your own instance of http://bugs.python.org/ for hacking > https://bitbucket.org/techtonik/pydotorg-bpo > > 2. Get Mercurial and run tests in VM > hg clone http://selenic.com/hg > cd hg/contrib/vagrant > vagrant up > vagrant ssh -c ./run-tests.sh > > Vagrant mounts current folder as /vagrant inside VM, so when I cd to this > folder and try to create symlink, I get a nasty error: > > vagrant ssh > > $ cd /vagrant > $ ln config.yml config.yml2 > ln: failed to create hard link `config.yml2' => `config.yml': > Operation not permitted > $ ln -s config.yml config.yml2 > ln: failed to create symbolic link `config.yml2': Protocol error > $ python -c "import os; os.symlink('config.yml', 'config.yml2')" > Traceback (most recent call last): > File "<string>", line 1, in <module> > OSError: [Errno 71] Protocol error > > >> > >> I am afraid the complain would be for SConstruct authors, not for SCons. > > > > Obviously. I think we all eat our own dog food? I imagine this will > affect > > few developers adversely. This adds new capability for symlinks which > > matches the Python API way of handling symlinks. > > Thinking about Python API in a positive way is a trap. Knowing the pitfalls > is a path to salvation. If our CCopy approach works, we may propose it for > inclusion. > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > http://two.pairlist.net/mailman/listinfo/scons-dev >
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev