Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158970 - symbolic links in NFS share became corrupted
Summary: symbolic links in NFS share became corrupted
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-27 11:38 UTC by oll
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-30 06:44:49 UTC


Attachments (Terms of Use)

Description oll 2005-05-27 11:38:25 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
symbolic links on NFS shares became "corrupted" (preferably became hard links)

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. create a file  on a NFS share : let's say "toto"
2. link it to "totolien" : ln -s toto totolien
3. move toto to toto-old : mv toto toto-old 
 ls -l totolien : it's a broken link : everything is ok
4. recrate toto : touch toto
 ls -l totolien : it points to the new toto : everything is ok
5. restart the station
6. do a "ls -l"



2. move it (so the link is broken
3.
  

Actual Results:  "totolien" points to "toto-old" (as I created a hard link)

Expected Results:  "totolien" should point to the new "toto" file

Additional info:

It appears always in this case :
Our gnome environment is installed on a NFS share on a solaris 2.9 server.
All stations automounts read-only (except mine) /opt/gnome
When I upgrade a gnome applications ( gnomecanvas this morning), I did
cd /opt/gnome/lib
mv libgnomecanvas-2.so.0.1000.0 libgnomecanvas-2.so.0.1000.0-OLD (I have to avoid deleted open file on all stations)
Here libgnomecanvas.so.1 become a dead link
Then i do a typical : ./configure --prefix=/opt/gnome && make && make install
libgnomecanvas-2.so.1 is no more a dead link and points now  to libgnomecanvas-2.so.0.1000.1 
Everything is fine.

In my stations , i do a "lsof|grep libgnomecanvas-2"
I have libgnomecanvas-2.so.0.1000.0-OLD : normal
I restart my session (not my stations)
I have now lsof|grep libgnomecanvas-2 : libgnomecanvas-2.so.0.1000.1

then I restart my station (so I flush all nfs caching).
lsof|grep canvas gives libgnomecanvas-2.so.0.1000.0-OLD : oooppss!
ls -l /opt/gnome/libgnomecanvas-2.so.1 points to libgnomecanvas-2.so.0.1000.0-OLD


I don't know where the troubles come from : 
Solaris 2.9 bug ? I doubt
gnome recreating links ? I doubt too

So I really things it's a NFS/Kernel/Fedora bug.

Comment 1 oll 2005-05-27 11:43:05 UTC
I dont know how to re-edit :
forget the 2 last lines in step to reproduce : it was a mistypping


Comment 2 oll 2005-05-30 06:44:49 UTC
I fill stupid : this is not a bug but a normal behaviour of libtool . Sorry


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