fs: Remove fs meta lock when PutObject() fails (#4114)

Removing the fs meta lock file when PutObject() encounters any error
during its execution, such as upload getting permatuerly cancelled
by the client.

cmd/fs-v1-helpers.go

@@ -20,6 +20,7 @@ import (
 	"io"
 	"os"
 	pathutil "path"
+	"runtime"
 )
 
 // Removes only the file at given path does not remove
@@ -377,3 +378,49 @@ func fsDeleteFile(basePath, deletePath string) error {
 
 	return nil
 }
+
+// fsRemoveMeta safely removes a locked file and takes care of Windows special case
+func fsRemoveMeta(basePath, deletePath, tmpDir string) error {
+	// Special case for windows please read through.
+	if runtime.GOOS == globalWindowsOSName {
+		// Ordinarily windows does not permit deletion or renaming of files still
+		// in use, but if all open handles to that file were opened with FILE_SHARE_DELETE
+		// then it can permit renames and deletions of open files.
+		//
+		// There are however some gotchas with this, and it is worth listing them here.
+		// Firstly, Windows never allows you to really delete an open file, rather it is
+		// flagged as delete pending and its entry in its directory remains visible
+		// (though no new file handles may be opened to it) and when the very last
+		// open handle to the file in the system is closed, only then is it truly
+		// deleted. Well, actually only sort of truly deleted, because Windows only
+		// appears to remove the file entry from the directory, but in fact that
+		// entry is merely hidden and actually still exists and attempting to create
+		// a file with the same name will return an access denied error. How long it
+		// silently exists for depends on a range of factors, but put it this way:
+		// if your code loops creating and deleting the same file name as you might
+		// when operating a lock file, you're going to see lots of random spurious
+		// access denied errors and truly dismal lock file performance compared to POSIX.
+		//
+		// We work-around these un-POSIX file semantics by taking a dual step to
+		// deleting files. Firstly, it renames the file to tmp location into multipartTmpBucket
+		// We always open files with FILE_SHARE_DELETE permission enabled, with that
+		// flag Windows permits renaming and deletion, and because the name was changed
+		// to a very random name somewhere not in its origin directory before deletion,
+		// you don't see those unexpected random errors when creating files with the
+		// same name as a recently deleted file as you do anywhere else on Windows.
+		// Because the file is probably not in its original containing directory any more,
+		// deletions of that directory will not fail with "directory not empty" as they
+		// otherwise normally would either.
+
+		tmpPath := pathJoin(tmpDir, mustGetUUID())
+
+		fsRenameFile(deletePath, tmpPath)
+
+		// Proceed to deleting the directory if empty
+		fsDeleteFile(basePath, pathutil.Dir(deletePath))
+
+		// Finally delete the renamed file.
+		return fsDeleteFile(tmpDir, tmpPath)
+	}
+	return fsDeleteFile(basePath, deletePath)
+}