As described in "Advanced Programming in the UNIX Environment" by Stevens, many programs use a pattern of mkstemp()/unlink()/write()/close(): This property of unlink is often used by a program to assure that a temporary file it creates won't be left around in case the program crashes. The process creates a file using either open or creat and then immediately calls unlink. The file is not deleted, however, because it is still open. Only when the process either closes the file or terminates (which causes the kernel to close all its open files) is the file deleted. According to the Single Unix Specification, this behavior must be provided by compliant systems: http://www.opengroup.org/onlinepubs/007904975/functions/unlink.html When the file's link count becomes 0 and no process has the file open, the space occupied by the file shall be freed and the file shall no longer be accessible. If one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file are closed. The below is a testcase. It will succeed (run forever) on all normal UNIX filesystems, but fails on every Samba share (including 3.0.1pre1) I have tested it on. Compile with: gcc -Wall -Werror muw.c -o muw ---- Begin muw.c ---- #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #define SIZE 1024 * 1024 int main (int argc, char **argv) { char buff[SIZE]; int i, fd; for (i = 0; i < SIZE; i++) buff[i] = 'Z'; for (;;) { char name[] = "./muw.XXXXXX"; if ((fd = mkstemp (name)) == -1) { fprintf (stderr, "mkstemp failed: %s\n", strerror (errno)); return 1; } if (unlink (name)) { fprintf (stderr, "unlink failed: %s\n", strerror (errno)); return 1; } fprintf (stdout, "writing %i bytes to %s ...\n", SIZE, name); if (write (fd, buff, SIZE) == -1) { fprintf (stderr, "write failed: %s\n", strerror (errno)); return 1; } } close (fd); return 0; } ---- End muw.c ----
Created attachment 366 [details] Testcase which shows the failure. Compile this with: gcc -Wall -Werror muw.c -o muw On normal UNIX file systems, it outputs: % ./muw writing 1048576 bytes to ./muw.JwS7gU ... writing 1048576 bytes to ./muw.5hJ6MW ... [forever] On Samba shares, it fails immediately: % ./muw writing 1048576 bytes to ./muw.Vc3lyV ... write failed: No such file or directory
nice bug report, but this is an smbfs issue, not Samba.
Ok. How do I report a bug against smbfs, in that case?
try the linux kernel mailing list or look at http://www.kernel.org/
Has this been tried against cifs vfs? Although POSIX emulation via CIFS is somewhat harder than with NFS, this kind of thing was why we wrote cifs vfs in the first place.