Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copy directory symlinks. #228

Merged
merged 1 commit into from Jun 15, 2012
Merged

Conversation

sbuss
Copy link
Contributor

@sbuss sbuss commented May 26, 2012

Linking symlinked directories causes a hardlink to be created, which
result in the source directory being wiped out during cleanup, so copy
the symlink.

Fixes #227

Linking symlinked directories causes a hardlink to be created, which
result in the source directory being wiped out during cleanup, so copy
the symlink.
@sbuss
Copy link
Contributor Author

sbuss commented May 27, 2012

I'm not actually sure this is the correct solution.

This hardlinking behavior was introduced in 9ab33879057ae857e92c9ebe340abd3990d25190. Prior to that commit, it looks like symlinked directories were created but not populated (though I could be mistaken).

The referenced commit caused symlinked directories to be hard linked (at least on some systems) which resulted in including them in the final package and introduced a bug where the original directories get wiped out.

The behavior introduced in this pull request follows the comments, which state "Symlinks should be copied as symlinks." I think that comment doesn't match the actual behavior, though.

I did some more virtualenv packaging testing after opening this pull request and the linking behavior seems inconsistent. Symlinked files are hard linked and the source of the file is included in the resulting package (this doesn't match the claimed behavior of copying a symlink), while directories are copied as symlinks and thus the generated packages aren't necessarily portable since the package now includes a symlink to a local directory.

As it stands, you shouldn't merge this since the behavior is inconsistent. I will fix my pull request, but I don't know what the actually correct behavior should be. I think it is to create the directory and copy its contents rather than symlink it, but I'd like your opinion first.

@sbuss
Copy link
Contributor Author

sbuss commented May 28, 2012

Perhaps the correct solution is to add a flag (--follow-symlinks or --dereference-symlinks) which follows all symlinks and includes the target files and directories in the package. By default, symlinks could be left as symlinks for both files and directories (which means that File.link should be replaced with FileUtils.copy_entry by default, since it preserves symlinks).

I'm not familiar enough with fpm to suggest a default which doesn't break expected behavior, though.

@jordansissel
Copy link
Owner

The hardlink implementation was made as a space-saving measure. File copying is stupid complex ;)

I think perhaps the best way to handle this would be to come up with examples that fail currently - as you have now. fpm invocations that do the wrong thing, etc.

@jordansissel
Copy link
Owner

I'll try and come up with a simple test using symlinks/etc that should fail and work on code to fix it.

jordansissel added a commit that referenced this pull request Jun 15, 2012
@jordansissel jordansissel merged commit 9319c3e into jordansissel:master Jun 15, 2012
prof-milki pushed a commit to prof-milki/xpm that referenced this pull request Dec 18, 2014
prof-milki pushed a commit to prof-milki/xpm that referenced this pull request Dec 27, 2014
jordansissel added a commit that referenced this pull request Apr 24, 2015
jordansissel added a commit that referenced this pull request Jun 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fpm 0.4.10 on osx 10.7.4 cripples python installation if packaging a virtualenv
2 participants