Deletion of symbolic link directories is inconsistent across systems

[HertzDevil]

The following will raise only on Windows, not on Unix-like systems:

Dir.mkdir("foo")
File.symlink("foo", "bar")
File.delete("bar") # Error deleting file: 'bar': Permission denied (File::AccessDeniedError)

Whereas the opposite holds for the following:

Dir.mkdir("foo")
File.symlink("foo", "bar")
Dir.delete("bar") # Unable to remove directory: 'bar': Not a directory (File::Error)

This might be due to the fact that "is a symbolic link" and "is a directory" are two distinct properties on Windows, rather than two values of a single property in POSIX. This is affecting the following spec since FileUtils.rm_r always calls File.delete on symlinks:

crystal/spec/std/file_utils_spec.cr

Lines 242 to 265 in c931553

	pending_win32 "doesn't follow symlinks" do
	with_tempfile("rm_r-removed", "rm_r-linked") do |removed_path, linked_path|
	link_path = File.join(removed_path, "link")
	file_path = File.join(linked_path, "file")
	test_with_string_and_path(removed_path) do |arg|
	Dir.mkdir(removed_path)
	Dir.mkdir(linked_path)
	File.symlink(linked_path, link_path)
	File.write(file_path, "")
	Dir.exists?(removed_path).should be_true
	Dir.exists?(linked_path).should be_true
	File.exists?(file_path).should be_true
	FileUtils.rm_r(arg)
	Dir.exists?(removed_path).should be_false
	Dir.exists?(linked_path).should be_true
	File.exists?(file_path).should be_true
	FileUtils.rm_rf(linked_path)
	end
	end
	end

What is the desired behavior here?

[jhass]

I think these are basically trying to mirror rm/rmdir. How does CMD del/rmdir behave in these situations?

I'd err on the UNIX side of things.

[HertzDevil]

This successfully deletes the symlink directory without touching the target:

> mkdir foo
> mklink /D bar foo
> rmdir bar

On Windows, if a directory is given to del, it automatically deletes the directory's children rather than the directory itself. In this case del bar traverses the symlink and deletes foo/*, leaving both directories intact. There isn't a command that fails when the argument names a directory.

Now CMD doesn't prevent you from creating a file symlink to a directory. It must then be deleted like a file and cannot be cd'ed into:

> mkdir foo
> mklink bar foo
> cd bar
The directory name is invalid.
> rmdir bar
The directory name is invalid.
> del bar

The opposite is also true, you can create a directory symlink to a file:

> echo 1 > foo
> mklink /D bar foo
> cd bar
The directory name is invalid.
> del bar
The directory name is invalid.
> rmdir bar

[straight-shoota]

I think we should stick with the current semantics, which are obviously inspired by Unix tools, and implement the same behaviour on Windows.

[HertzDevil]

So, am I getting this right?

Windows

Method	Symlink?	Type	Action
File.delete	No ✖	File	call Crystal::System::File.delete
Dir.delete	No ✖	File	raise File::Error
File.delete	No ✖	Directory	raise File::Error
Dir.delete	No ✖	Directory	call Crystal::System::Dir.delete
File.delete	Yes ✔	File	call Crystal::System::File.delete
Dir.delete	Yes ✔	File	raise File::Error
File.delete	Yes ✔	Directory	raise File::Error call Crystal::System::Dir.delete
Dir.delete	Yes ✔	Directory	call Crystal::System::Dir.delete raise File::Error

POSIX

Method	Symlink?	Type	Action
File.delete	No ✖	File	call Crystal::System::File.delete
Dir.delete	No ✖	File	raise File::Error
File.delete	No ✖	Directory	raise File::Error
Dir.delete	No ✖	Directory	call Crystal::System::Dir.delete
File.delete	Yes ✔	N/A	call Crystal::System::File.delete
Dir.delete	Yes ✔	N/A	raise File::Error

This should make FileUtils.rm_r work without any modifications.

[straight-shoota]

Looks good. The behaviour of works vs. does not work is identical on Windows on POSIX when expanding the N/A type into File and Directory.