[boost] Re: Filesystem: remove_all should not follow symlinks

From: Ross Smith (rosss_at_[hidden])
Date: 2003-11-18 14:39:55

Beman Dawes wrote:
> 
> [Help needed from POSIX programmers on the following.]
> 
> * Does S_ISLNK() return true only for symbolic links, and never for 
> regular reference-counted links? If so, that means is_link() never 
> returns true except for symbolic links, so I'd rather call it 
> is_symbolic_link().

Yes, S_ISLNK only identifies symlinks, not hardlinks. Hardlinks
(reference counted links) are just regular files -- when you see a
directory listing, everything there is a hardlink; no particular
distinction is made between files with one link and files with two
or more. A symlink points to a (named) hardlink, not directly to the
(anonymous) underlying file.

> [Help needed from Win32 programmers on the following.]
> 
> * Can is_symbolic_link() just return false on Windows?
> 
> Windows does have some similar concepts - shortcuts and journals - but 
> the behavior seems different from a POSIX-style symbolic link. 
> Particularly, shortcuts by default seem to exhibit shallow rather than 
> deep behavior, and seem more an application (shell) artifact rather than 
> a kernel feature. But maybe I don't understand them - any pointers to an 
> underlying API would be appreciated. And I certainly don't understand 
> journal points. Windows does have reference counted hard links, very 
> similar to POSIX links, but that isn't the issue here.

There are differences between Unix symlinks and Windows shortcuts;
it's hard to say whether they're big enough to justify treating
Windows shortcuts as something fundamentally different. It's true that
they're really part of the shell rather than the filesystem; ordinary
filesystem manipulation functions don't treat them as special (i.e.
don't resolve them to their target files). To handle them
programmatically you need to delve into the shell's COM interface
(look under IShellLink in MSDN).

On balance I think always returning false would be justified. Users
of the Windows GUI would tend to think of shortcuts as symlinks, but
programmers wouldn't; code that doesn't make a special effort to deal
with them won't see them as links. On the other hand, code that needs
to interact with the GUI _does_ need to deal with them to avoid
surprising the user.

I'm not sure what you mean by "shallow rather than deep behaviour" --
if you mean that a shortcut only points at a name rather than the real
file, and so gets broken if the file is renamed, the same is true of
Unix symlinks.

I don't know anything about "journals"; in fact I'd never heard of
them until now.

-- 
Ross Smith ...................... Pharos Systems, Auckland, New Zealand
     "No one really listens to anyone else. Try it for a while
     and you'll see why." -- Mignon McLaughlin