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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-11-22 10:43:39

At 05:53 PM 11/21/2003, Peter Dimov wrote:
 >Beman Dawes wrote:
 >>
 >> Good questions. For both reference-counted and symbolic links, and for
 >> every operation, we need to know if the operation has shallow or deep
 >> semantics.
 >
 >You keep talking about "reference-counted and symbolic links" but these 
two
 >do not belong in the same sentence, as has already been pointed out.
 >
 >A "link" is Unix terminology for a directory entry. A directory entry
 >points to an i-node which has a reference count. This is why the delete
 >operation is called "unlink", it removes the directory entry, but not
 >necessarily the file. When you have two directory entries for the same
 >file, both are equal. It doesn't matter which one came first.

Sure. And although the terminology is a bit different, the same description 
applies to NTFS.

 >It doesn't make sense to talk about shallow or deep semantics here.

That's usually correct, but there are a few query operations where the 
shallow/deep issue might matter, depending on the operating system. 
Size/date/time being examples.

 >A symbolic link is a special kind of directory entry that points to 
another
 >directory entry.

That's correct for POSIX, if I understand the POSIX docs correctly.

But on NTFS (and perhaps other Windows file systems) it gets much murkier. 
The feature roughly equivalent to a POSIX symbolic link is the shortcut 
file (with an extension of .lnk, although you can add additional extensions 
via the registry). Shortcut files appear to be application features rather 
than operating system features. I just read that earlier this morning, and 
it would explain why some programs resolve shortcuts and some don't, why 
the shortcuts created by Windows Explorer appear to function differently 
that the shortcuts created by ln -s, and why the Windows Platform SDK 
doesn't appear to have API calls directly equivalent to the POSIX 
symlink(), lstat(), etc.

--Beman