os: Remove/RemoveAll should remove read-only files on Windows

[adg]

On Unix systems, Remove/RemoveAll will work even if the files are chmod 0600. On windows, Remove/RemoveAll will not remove a file marked as read-only. If you want to write a Go program that deletes a file, you need to take special care on windows. That's sad.

Since we determine the semantics of Remove/RemoveAll, we could make this "just work" and save our users some effort.

Discussion started here: https://go-review.googlesource.com/2930

[minux]

Code change is easy. Any objections to this idea?

We will need to call out this change in the Go 1.5 release note, but
I don't think it should surprise users.

BTW, once this is in, we can remove the workaround in CL 2930 and
CL 2089 (resetReadOnlyFlagAll function).

[alexbrainman]

I object. I think there is confusion here about what Windows file "read-only" attribute does. It not just prevents from making changes to the contents of the file. It also prevents from the file to be deleted.

C:\tmp\aaa>echo > a.txt

C:\tmp\aaa>attrib +r a.txt

C:\tmp\aaa>del a.txt
C:\tmp\aaa\a.txt
Access is denied.

C:\tmp\aaa>attrib -r a.txt

C:\tmp\aaa>del a.txt

C:\tmp\aaa>

On linux it would be similar to:

$ ls
$ mkdir a
$ touch a/f1
$ touch a/f2
$ ls -l
total 4
drwxr-xr-x 2 brainman brainman 4096 Jan 16 10:54 a
$ rm a/f1
$ chmod a-w a
$ ls -l
total 4
dr-xr-xr-x 2 brainman brainman 4096 Jan 16 10:54 a
$ rm a/f2
rm: cannot remove `a/f2': Permission denied
$ chmod u+w a
$ ls -l
total 4
drwxr-xr-x 2 brainman brainman 4096 Jan 16 10:54 a
$ rm a/f2
$ rmdir a
$

Basically you have to change the flag before you will be allowed to delete the file.

Also some explanation from http://www.oreilly.com/openbook/samba/book/ch05_03.html

DOS filesystems are not designed for multiple users, and so its designers decided that read-only means "protected against accidental change, including deletion," rather than "protected against some other user on a single-user machine." So the designers of DOS prohibited removal of a read-only file. Even today, Windows file systems exhibit the same behavior.
<<<

I don't see wining this argument, but I am trying.

Alex

[minux]

You're still talking about Windows file deletion semantics, but
the os package is not bound by Windows file deletion semantics.

To put it another, should the API refrain from deleting any file not
writable by the current user on other platforms?

Why should we have this distinction on the supposedly portable
os package.

[alexbrainman]

Your argument is "os.Remove must make every effort to delete the file". Isn't it?

But, if we assume that premise, then we should do the same on every platform. For example in my example above:

$ rm a/f2
rm: cannot remove `a/f2': Permission denied

should we try and change 'a' directory mode and try to delete a/f2 again? Because that is what you're effectively proposing for windows os.Remove.

To me it is all about being reasonable here. The "read-only" flag is set for a reason. Lets not delete the file until we understand that reason.

To put it another, should the API refrain from deleting any file not
writable by the current user on other platforms?

I say we should leave thing as they are. We use "standard" system API. Whatever it does is most correct for general case scenario.

Alex

[minux]

We can change the permission of the file itself, but we shouldn't
change the permission of its parent. That's the border line.

[minux]

I say we should leave thing as they are. We use "standard" system API.
Whatever it does is most correct for general case scenario.

In that case, let's change the documentation for os.Remove to:

Remove just calls the standard os remove (delete) file to remove the file
or directory. It does what the standard OS-specific API does.

Is that acceptable to you? This is essentially your position.

[mattn]

I also do not agree to this change. It's overwork. If you want, let's put makerelease_windows.go and add func removeAll.

[alexbrainman]

I am fine with documentation change. But I think that everyone understands that OS file / permissions might prevent you from removing file. No one complaining about inability to remove opened file on windows. Same for removing current directory.

The problem is us. We assume that os package provides same behaviour everywhere. But sometimes it cannot.

Alex

[minux]

Why it's overwork?

When I write os.Remove(filename), I truly want it to delete the file.

I don't want to write system specific code for each code, otherwise
what's the point of providing os.Remove?

Why not just force the user to use syscall.Unlink and syscall.DeleteFile
instead? Is providing os.Remove overwork too?

[alexbrainman]

@minux

When I write os.Remove(filename), I truly want it to delete the file.

I think the real issue we should be discussing here (if we care), is why these files have "read-only" flag. Who set the flag and why? Perhaps, once we understand the reasoning, we can decide what to do with the issue at hand.

If we care.

Alex

[mattn]

In generally, we have to do care for windows about file deletion. For example: when some files are opened by another applications, so the file is locked with opening file, the deletion of file should be fail. This changing spec will solve this issue. But we will get another issue. So I'm thinking we have better not do.

[tv42]

Unix chmod a-w on the file itself is irrelevant for removing it; unix controls removing by directory permissions.

The Windows file read-only flag is more like chattr +i (immutable) on Linux, and such a file "cannot be deleted or renamed" (see chattr(1)).

I don't think os.Remove/RemoveAll should do anything extra to make the deletion succeed. What next, change ACLs to allow the delete? That road leads to madness.