<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> Treating symbolic links as files for the simple needs of the FSUtils<BR>> module sounds OK, but the rm should of course only remove the link.<BR><BR>
<BR>
Right: my understanding and intent is that just the link, not the link target, is deleted.<BR>
I can't guarantee at this point, but that was my understanding and intent.<BR>
There was already *some* existing behavior. If you just delete the link, it'd do something.<BR>
What didn't work is enumerating/stat'ing a link whose target doesn't exist, en route to deleting the link.<BR>
<BR>
<BR>
(In our actual use, we do delete the target, because what we are enumerating and deleting<BR>
both of the link and its target.)<BR>
<BR>
> for more sophisticated file systems which are more or less standard<BR>> these days. Perhaps a careful review/redesign of this area would be<BR>> a good idea, too.<BR><BR>
<BR>
Even if they aren't "standard" -- even if not every host has them -- certainly many hosts do.<BR>
I have done so much programming in the absence of symbolic links..I'm very uncertain how to reason about them.<BR>
They allow for infinite loops in the namespace.<BR>
Hardlinks too add additional confusion/meaning.<BR>
<BR>
<BR>
Possible problem is that historically a symlink to an existing directory was reported as a directory.<BR>
Now it is reported as a file.<BR>
We could, expensively, first try stat, and if it fails for file/path not found, lstat instead.<BR>
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.<BR>Or possibly return the type as a new type, symlink, but no existing caller would know how to handle that.<BR>
<BR>
Probably adding another bit is reasonable, and update the Trestle file open dialogs to use a different icon.<BR>
<BR>
- Jay<BR><BR> </body>
</html>