Bug 9837

Summary: NFS filesystems don't reflect recent changes
Product: [Retired] Red Hat Linux Reporter: Scott Hankin <shankin>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Ben Levenson <benl>
Severity: high Docs Contact:
Priority: medium    
Version: 7.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-08 19:23:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.