lib/rmobj.c: fix warning on FUSE fs

This warning can appear on FUSE fs in cleanup():
TWARN : tst_tmpdir.c:219: tst_rmdir: rmobj(...) failed: unlink( .../.fuse_hidden#####) failed; errno=2: No such file or directory

rmobj recursively goes through directory entries and unlinks files there. During the time between getting the entry and calling unlink() the file can be deleted by FS.

We can fix it by skipping ENOENT errno as it is possible that a file might not exist by that time.

---
 lib/rmobj.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

index a9de59c..aa5bb6a 100644
@@ -192,8 +192,13 @@ int rmobj(char *obj, char **errmsg)
 			}
 		}
 	} else {
-		/* object is not a directory; just use unlink() */
-		if (unlink(obj) < 0) {
+		/* object is not a directory; just use unlink()
+		 * Note: skip ENOENT errno as it might catch hidden temporary
+		 * files (e.g. can be created by FUSE FS) when listing directory
+		 * entries on the previous stage, but the file could have been
+		 * removed by FS already.
+		 */
+		if (unlink(obj) < 0 && errno != ENOENT) {
 			if (errmsg != NULL) {
 				sprintf(err_msg,
 					"unlink(%s) failed; errno=%d: %s", obj,

1.7.1

Hi!

Isn't this the same problem as the NFS one? I.e. unlinked but still open files?

But in this case it looks like the file was still there shortly after the fd has been closed, right? I wonder if that is a bug or not. I would expect that the file is no longer in the directory listing once the close() has returned from kernel.

Cyril Hrubis
[email protected]

Hi,

No, checked syscalls/* tests, they all are closing fds before tst_rmdir().

It happens only if test does unlink(fd), then close(fd). If we change a test so it calls close(fd) first, then unlink(fd), then ".fuse_hidden" never being
created to store data about unlinked but still open file, and we won't have this warning too. It's just another way to workaround it in the tests.

Hmm, may be it is a bug, for a short period of time after close() we can still have this temporary file listed. OK, I will check it with our developers.

Thanks,
Alexey