[Remind-Fans] tkremind kills symlinks

[David A. De Graaf]

On Thu, Jun 24, 2010 at 03:25:21PM -0400, David F. Skoll wrote:
> Ben Love wrote:
> 
> > # Fake wish/sh combined syntax.
> > set RemindFile $(readlink -f ~/.reminders)
> 
> Weeelll...
> 
> > Perhaps it's a lot more complicated than that though.
> 
> Yes.  You may have a chain of symlinks; you have to follow them all.
> You may have a circle of symlinks, in which case you need to break the loop
> and complain.
> 
> All in all, a fair amount of work.  I'd much rather say "Don't do that!"
> and leave it at that. :)

Well, all I know is that vi handles the problem.
I've edited countless symlinked files without issue.
It also handles multiple concurrent attempts to edit the same file.
As a functional illiterate in programming, I have no idea how hard this
may be.

Perhaps it's worth reconsidering the "atomicity" of the copy command.
To me, it's a much greater problem when a symlink is knowingly
destroyed than the tiny risk of two concurrent writers interfering.
Perhaps the copy can be forced to be "pseudo-atomic" by using a flag file.
Or compare the newly written file against its source?  

According to  man nfs  there are a number of simple ways to force immediate
writing to the server, regardless of the mount option 'sync|nosync',
but some action is required.

-- 
	David A. De Graaf    DATIX, Inc.    Hendersonville, NC
	dad at datix.us         www.datix.us