Bug 998 - Writes to unlinked files fail
Writes to unlinked files fail
Status: RESOLVED WONTFIX
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.1
Other other
: P3 normal
: none
Assigned To: Samba Bugzilla Account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-22 15:54 UTC by Amos Waterland
Modified: 2004-05-03 08:53 UTC (History)
0 users

See Also:


Attachments
Testcase which shows the failure. (754 bytes, text/plain)
2004-01-22 16:00 UTC, Amos Waterland
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Amos Waterland 2004-01-22 15:54:04 UTC
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 ----
Comment 1 Amos Waterland 2004-01-22 16:00:59 UTC
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
Comment 2 Gerald (Jerry) Carter 2004-04-22 19:34:10 UTC
nice bug report, but this is an smbfs issue, not Samba.
Comment 3 Amos Waterland 2004-04-25 15:41:02 UTC
Ok.  How do I report a bug against smbfs, in that case?
Comment 4 Gerald (Jerry) Carter 2004-04-26 14:55:47 UTC
try the linux kernel mailing list or look at http://www.kernel.org/
Comment 5 Steve French 2004-05-03 08:53:38 UTC
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.