Re: [Users] [ET Trac] [Einstein Toolkit] #453: Formaline deletes files if lib and src are symlinks
Hello all,
Yes, that is the idea. The patch as stop-gap measure, and then trying to understand the real cause of the problem and correcting git-add-thorn.pl.
I do not think that Mac OS allows hard links to directories for regular users. With these, one can create directory structures that are not trees, which would break many Unix expectations; in particular, one can create directory structures disconnected from the root directory and hence unreachable. Root can call the "link" syscall (maybe even from the "ln" command, possibly with a special option) to do this, but it's highly discouraged.
If this issue is just that Mac OS allows hard links for directories then simply changing link() to symlink() for directories: http://perldoc.perl.org/functions/symlink.html should fix the issue, shouldn't it?
Something like:
if(-d $object) { symlink(...) } else { link(...) }
Yours, Roland
On Tue, Jun 21, 2011 at 1:56 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello all,
Yes, that is the idea. The patch as stop-gap measure, and then trying to understand the real cause of the problem and correcting git-add-thorn.pl.
I do not think that Mac OS allows hard links to directories for regular users. With these, one can create directory structures that are not trees, which would break many Unix expectations; in particular, one can create directory structures disconnected from the root directory and hence unreachable. Root can call the "link" syscall (maybe even from the "ln" command, possibly with a special option) to do this, but it's highly discouraged.
If this issue is just that Mac OS allows hard links for directories then simply changing link() to symlink() for directories: http://perldoc.perl.org/functions/symlink.html should fix the issue, shouldn't it?
Something like:
if(-d $object) { symlink(...) } else { link(...) }
The overall goal of this code is to create a shadow hierarchy of the actual thorn with all relevant files. For this, all directories are created via mkdir, and all files are hardlinked. After calling "git add", this shadow directory is deleted again. (This is necessary because "git add" can't be made to follow symbolic links.)
In other words, the link command should never encounter directories. An expression "! -type d" to a previous find should prevent this. The error may be somewhere else -- maybe in the find command?
I never expected to have to follow symbolic links within thorns (including within the flesh). I am not sure it is a good idea to follow them, because symbolic links can easily be circular. I rather think symbolic links should be placed into the git repository "as is".
-erik
On Tue, Jun 21, 2011 at 02:40:52PM -0400, Erik Schnetter wrote:
The overall goal of this code is to create a shadow hierarchy of the actual thorn with all relevant files. For this, all directories are created via mkdir, and all files are hardlinked. After calling "git add", this shadow directory is deleted again. (This is necessary because "git add" can't be made to follow symbolic links.)
This is what 'cp -rlL' should do, but we cannot rely on that because that might not work on all machines?
Frank
On Tue, Jun 21, 2011 at 3:43 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Tue, Jun 21, 2011 at 02:40:52PM -0400, Erik Schnetter wrote:
The overall goal of this code is to create a shadow hierarchy of the actual thorn with all relevant files. For this, all directories are created via mkdir, and all files are hardlinked. After calling "git add", this shadow directory is deleted again. (This is necessary because "git add" can't be made to follow symbolic links.)
This is what 'cp -rlL' should do, but we cannot rely on that because that might not work on all machines?
Yes, neither -r nor -l are standard options.
We could use e.g. tar (or cpio?) to copy the whole directory structure and forget about using hard links. This would be reliable. But it would not solve Barry's original problem, because it would not follow the symbolic links.
-erik
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Roland Haas