Bug 9837 - NFS filesystems don't reflect recent changes
Summary: NFS filesystems don't reflect recent changes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils
Version: 7.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-28 18:14 UTC by Scott Hankin
Modified: 2007-04-18 16:26 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-01-08 19:23:40 UTC
Embargoed:


Attachments (Terms of Use)

Description Scott Hankin 2000-02-28 18:14:19 UTC
In many instances in our code,  a file created via NFS on a local host
can't be seen after its creation.  Our product creates files over NFS, even
on the local host.  We are seeing a situation where we create a file or
directory, the creation returns success, but when the path is passed to
another process on the same machine, that process can't see the new
file/directory.  The file is there, as it is visible if not viewed over
NFS, but NFS claims it isn't there, for a substantial length of time (> 5
seconds.)

We have worked around this problem in some cases by creating a dummy file
in the directory in question, locking it (lockf), unlocking it, and
removing it.  In some of the problem areas, it is necessary to attempt to
access the path, component by component, from the leaf, until a directory
is found which is accessable, then create and destroy the locks all the way
down.  However, it is impractical to place this before every open, fopen
and opendir it our code.

Our product runs on many other Unix platforms, and no others exhibit this
behavior.

Comment 1 Cristian Gafton 2000-08-09 02:34:00 UTC
assigned to johnsonm

Comment 2 Steve Dickson 2003-01-08 19:23:40 UTC
I was not able to reproduce this in the latest release.


Note You need to log in before you can comment on or make changes to this bug.