#10140 NORM Not Tri: External device large Journal does not display

[Zarro Boogs per Child]

#10140: External device large Journal does not display
----------------------------------------+-----------------------------------
           Reporter:  mikus             |       Owner:  tomeu                            
               Type:  defect            |      Status:  new                              
           Priority:  normal            |   Milestone:  Not Triaged                      
          Component:  journal-activity  |     Version:  Development build as of this date
         Resolution:                    |    Keywords:                                   
        Next_action:  never set         |    Verified:  0                                
Deployment_affected:                    |   Blockedby:                                   
           Blocking:                    |  
----------------------------------------+-----------------------------------

Comment(by mikus):

 Replying to [comment:2 Quozl]:
 > Diagnosis: the journal is continuing to read the media while exploring
 an infinite filesystem loop caused by symbolic links.

 The Journal may have gotten into a loop -- but I think it really shouldn't
 have.

 /media/CAVE is my "grab bag" USB stick, onto which a year and a half ago I
 happened to have saved the then content of /home/olpc (which included the
 '/home/olpc/isolation' directory maintained by Rainbow).

 Following up on what you found in shell.log:  'ls' shows there exists in
 directory /media/CAVE/olpc/isolation/1/uid_to_home_dir/10015 the symbolic
 link "instance -> ." (which must have been created by whichever Activity
 was run under ID 10015, or created by Rainbow).

 I'm going by the fact that 'ls -lRL' handles
 /media/CAVE/olpc/isolation/1/uid_to_home_dir/10015;  so do 'du -L' and
 'find'.  If those commands aren't bothered by the bum symbolic link,
 Journal should be able to handle it, also.

 ----

 If I remember correctly, when I went into a text console and looked at the
 output of 'top', I did NOT see anything that made me think that Journal
 (i.e., 'python') were still using CPU after the initial dozen seconds.
 The absence of CPU use by Journal makes me suspect that Journal completed
 its scan of the device, or else got an abnormal termination of that scan
 -- but NEVER switched its display away from the "progress bar" screen
 meant to indicate "working on the /media/CAVE content".

-- 
Ticket URL: <http://dev.laptop.org/ticket/10140#comment:3>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system