Skip to Content.
Sympa Menu

sm-sorcery-bugs - [SM-Sorcery-Bugs] [Bug 13400] symlinks for config files should not be reaped

sm-sorcery-bugs AT lists.ibiblio.org

Subject: Bugs for Sorcery are reported here

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-sorcery-bugs AT lists.ibiblio.org
  • Subject: [SM-Sorcery-Bugs] [Bug 13400] symlinks for config files should not be reaped
  • Date: 9 Mar 2007 21:32:21 -0000

http://bugs.sourcemage.org/show_bug.cgi?id=13400





------- Additional Comments From sobukus AT sourcemage.org 2007-03-09 15:32
-------
Sheesh, Andrew, this is no holy war!
I'm sorry, I'm sorry, I'm sorry, I'm sorry.

Long speeches only offer new proof of my blatant ignorance and unhelpfulness,
so I make my essential points clear how I see it now -- without the anger and
impatience I forwared from my friend and without too much prose:

1. A user may want to utilize symlinks for managing his config files,
possibly
having some central repo (on another filesystem) and links pointing into that.
We should not put that to question -- it's his _choice_.

2. Sorcery should make that possible by preserving whatever is at the place
of
a config file in case admin changed it.

I don't see the sense in the way the distinction is currently made. Symlinks
always to the dumpster, real files through the check first.
What would make sense to me is that one takes _additional_ care for symlinks
-
not reaping it even if the contents didn't change (treat the placement of a
symlink itself as an admin change).
I don't claim that there is no possible sense in the current unconditional
deletion, I just don't see it.

All I want is to settle on the intended behaviour of the reaper concerning
symlinks (obviously including preservation of symlinks;-) and have a patch of
mine or anyone else's included that implements that. If there are strong
reasons for the behaviour how it is right now, I'd like to know them.
Of course a symlink is not totally identical with a file and there open the 2
bits of decision with 4 possibilities (actually, if we want to allow admins
to
have symlinks hat can be pointing into the void at the moment of casting,
there's a bit more).
When there are pitfalls in changing the current works into something
symlink-friendly, please let's find and name them explicitly.

Now I made half a speech again. Dammit.
Andrew, please ignore the parts that make your blood boil (including that
offending sentence;-).
I just want to be able to change config files into symlinks and have that
honored by sorcery. I'll happily rework my patch when we can settle on
the "right thing".

Jeremy:Sheesh, Andrew, this is no holy war!

Long speeches only offer new proof of my blatant ignorance and unhelpfulness,
so I make my essential points clear how I see it now -- without the anger and
impatience I forwared from my friend and without too much prose:

1. A user may want to utilize symlinks for managing his config files,
possibly
having some central repo (on another filesystem) and links pointing into that.
We should not put that to question -- it's his _choice_.

2. Sorcery should make that possible by preserving whatever is at the place
of
a config file in case admin changed it.

I don't see the sense in the way the distinction is currently made. Symlinks
always to the dumpster, real files through the check first.
What would make sense to me is that one takes _additional_ care for symlinks
-
not reaping it even if the contents didn't change (treat the placement of a
symlink itself as an admin change).
I don't claim that there is no possible sense in the current implementation,
I
just don't see it.

All I want is to settle on the intended behaviour of the reaper concerning
symlinks (obviously including preservation of symlinks;-) and have a patch of
mine or anyone else's included that implements that. If there are strong
reasons for the behaviour how it is right now, I'd like to know them.
Of course a symlink is not totally identical with a file and there open the 2
bits of decision with 4 possibilities (actually, if we want to allow admins
to
have symlinks hat can be pointing into the void at the moment of casting,
there's a bit more).
When there are be pitfalls in changing the current works into something
symlink-friendly, please let's find and name them explicitly.

Now I made half a speech again. Dammit.
Andrew, please ignore the parts that make your blood boil (including that
offending sentence;-).
I just want to be able to change config files into symlinks and have that
honored by sorcery. I'll happily rework my patch when we can settle on
the "right thing".

Jeremy:
Of course some thought is needed. I got impatient because I feared the bug
getting lost after I saw no sign of someone taking notice after two weeks.
And I argue that hardlinks are what one should use anyway.
Symlinks work in situations where hardlinks don't. Hardlinks don't show you
what they are pointing at unless you start comparing inode numbers.
Looking at the link count of a file doesn't tell you _which_ other hardlink
points to it (there could be other hardlinks unrelated to the one used as
config file). Please accept that there may be people who prefer handling the
initially described situation with symlinks, because there are (I'm counting
my friend and me now, that makes two, which qualifies for plural;-).

--
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.




Archive powered by MHonArc 2.6.24.

Top of Page