[Scons-dev] New symlink copy support
William Blevins
wblevins001 at gmail.com
Tue Jul 29 20:43:12 EDT 2014
>
> 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 <techtonik at gmail.com>
wrote:
> On Tue, Jul 29, 2014 at 2:39 AM, William Blevins <wblevins001 at 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 at scons.org
> http://two.pairlist.net/mailman/listinfo/scons-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140729/bfa67534/attachment-0001.html>
More information about the Scons-dev
mailing list