[M3devel] rmrec problems

[Jay K]

> Treating symbolic links as files for the simple needs of the FSUtils
> module sounds OK, but the rm should of course only remove the link.

 
Right: my understanding and intent is that just the link, not the link target, is deleted.
I can't guarantee at this point, but that was my understanding and intent.
There was already *some* existing behavior. If you just delete the link, it'd do something.
What didn't work is enumerating/stat'ing a link whose target doesn't exist, en route to deleting the link.
 
 
(In our actual use, we do delete the target, because what we are enumerating and deleting
both of the link and its target.)
 
> for more sophisticated file systems which are more or less standard
> these days. Perhaps a careful review/redesign of this area would be
> a good idea, too.

 
Even if they aren't "standard" -- even if not every host has them -- certainly many hosts do.
I have done so much programming in the absence of symbolic links..I'm very uncertain how to reason about them.
They allow for infinite loops in the namespace.
Hardlinks too add additional confusion/meaning.
 
 
Possible problem is that historically a symlink to an existing directory was reported as a directory.
Now it is reported as a file.
We could, expensively, first try stat, and if it fails for file/path not found, lstat instead.
That might work. But I'd rather leave it as is. Maybe add another bit to the file status to indicate it is a symlink.
Or possibly return the type as a new type, symlink, but no existing caller would know how to handle that.
 
Probably adding another bit is reasonable, and update the Trestle file open dialogs to use a different icon.
 
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100804/d3af21e0/attachment-0002.html>