write to file opened using O_RDWR returns EBADF - SMB

This is a discussion on write to file opened using O_RDWR returns EBADF - SMB ; Hi, I have encountered a curious error with an application being developed on Linux (RedHat enterprise 4). We have a test set-up that is using a windows directory mounted with Samba Version 3.0.10-1.4E.6. strace clearly shows the file being opened ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: write to file opened using O_RDWR returns EBADF

  1. write to file opened using O_RDWR returns EBADF

    Hi,
    I have encountered a curious error with an application being
    developed on Linux (RedHat enterprise 4). We have a test set-up that is
    using a windows directory mounted with Samba Version 3.0.10-1.4E.6.
    strace clearly shows the file being opened using O_RDWR. We
    subsequently perform a number of lseek's and reads. At one particular
    repeatable point with a particular input dataset a write following an
    lseek fails with EBADF. I understand that EBADF is being used as a
    substitute for something more accurate, but what is this something and
    how can I track down the problem. I haven't been able to track down any
    documentation for what this might mean. Could it be a Samba bug?
    The same program has no problems when the target directory is a local
    directory or mounted using NFS. Another program (which actually a
    parent process that spawns this one) is looking at the same file and
    creating POSIX advisory read locks on it. The locking interactions of
    the two programs have been tested and found to work outside of this
    context. The program experiencing EBADF still experiences it will all
    fcntl locking code removed. Another item of interest is that fcntl
    F_GETFL 'works'. It returns a zero error code and flags indicating the
    file is open O_RDWR. An embedded call to system("lsof") also shows the
    file descriptor as open for update.
    Can anyone shed some light on this please?
    Regards,

    Bruce.


  2. Re: write to file opened using O_RDWR returns EBADF


    tortoise underscore 74 at yahoo. nospam co.uk wrote:
    > Hi,
    > I have encountered a curious error with an application being
    > developed on Linux (RedHat enterprise 4). We have a test set-up that is
    > using a windows directory mounted with Samba Version 3.0.10-1.4E.6.
    > strace clearly shows the file being opened using O_RDWR. We
    > subsequently perform a number of lseek's and reads. At one particular
    > repeatable point with a particular input dataset a write following an
    > lseek fails with EBADF. I understand that EBADF is being used as a
    > substitute for something more accurate, but what is this something and
    > how can I track down the problem. I haven't been able to track down any
    > documentation for what this might mean. Could it be a Samba bug?
    > The same program has no problems when the target directory is a local
    > directory or mounted using NFS. Another program (which actually a
    > parent process that spawns this one) is looking at the same file and
    > creating POSIX advisory read locks on it. The locking interactions of
    > the two programs have been tested and found to work outside of this
    > context. The program experiencing EBADF still experiences it will all
    > fcntl locking code removed. Another item of interest is that fcntl
    > F_GETFL 'works'. It returns a zero error code and flags indicating the
    > file is open O_RDWR. An embedded call to system("lsof") also shows the
    > file descriptor as open for update.
    > Can anyone shed some light on this please?
    > Regards,
    >
    > Bruce.


    I note from LSOF that both the parent and
    child process have the same value (3) for the file descriptor though it
    claims the child has
    it open for writing whereas the parent is read only.

    The problem seems to be subtley related to inheritance of handles.
    If the file is opened O_RDWR in the parent process the problem
    disappears.
    This might suggest that the problem is a missing fcntl( blah, F_SETFD,
    FD_CLOEXEC)
    however adding that fails to resolve the problem.


+ Reply to Thread