Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 396644

Summary:	Shell: can't use commands on a file until doing 'ls'
Product:	[ECD] Orion	Reporter:	libing wang <libingw>
Component:	Node	Assignee:	libing wang <libingw>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	grant_gayed, majorzbzzn, mamacdon
Version:	1.0	Keywords:	helpwanted
Target Milestone:	2.0 M2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description libing wang

2012-12-14 14:38:01 EST

1. Open the shell page.
2. cd to some directory that has files in it.
3.Try to run a command that takes a filename as input. For example: node start foo.js (where foo.js is in your CWD).
4. The shell won't let you enter the command.
5. Type ls, then try the command again. Now it works.

It seems you need to prefill the shell's file list by doing ls before filename completions will work.

Comment 1 libing wang

2012-12-14 15:06:21 EST

Transferred https://github.com/mamacdon/orionode/issues/7 to here.
Histories from the conversations:

MArk:
Hey Boris. If you'd like to start looking at this, go right ahead. (GitHub won't let me assign it to you, but don't let that stop you from diving in -- we just can't merge in any pull requests until we get the legal jazz worked out.)

I suspect the actual bug is in the orion.client library that we pick up from Orion proper, so if you find a fix, you can actually contribute it back to the upstream orion.client (which is fully-open for contributions) and Orionode can just merge it in.

Good places to start debugging are shellPageFileService.js and shellPage.js in the lib/orion.client/bundles/org.eclipse.orion.client.core/web/shell/plugins folder.

Boris:
After some investigation I found a possible fix:
in shellPageFileService.js line 241 should be
if (node.Directory === undefined && node.ChildrenLocation) {

Since the Directory property may be set earlier it seems wrong to set it again based solely on the ChildrenLocation property.

Could you please check it?

Thanks,
Boris.


Libing:

Hi, Boris. Thanks for the patch. Mark is on vacation now so I will have a look at this.
By the way, we are pushing all the code to Orion client repo now.
I am transferring this issue to bugzilla. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=396644)
If you are interested you can also run this query to see all other open issues.
https://bugs.eclipse.org/bugs/buglist.cgi?classification=Eclipse&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Node&product=Orion

Comment 2 libing wang

2012-12-14 15:19:02 EST

Bug 394580 is a dup of this.

Comment 3 libing wang

2012-12-18 16:02:58 EST

Hi, Boris, I tried you suggestion but it did not work. It must be some where else.
After CD, if you refresh the browser it works.

Comment 4 libing wang

2012-12-19 11:21:48 EST

After talking to Boris and cleared my browser cache, the fix seemed to work.
But the regular orion does not have this issue and the fix happens on the generic place.
Not sure if there are something happened deep on the node file service.

Comment 5 libing wang

2012-12-19 11:22:24 EST

Grant, what do you think about the fix?

Comment 6 Boris Kozorovitzky

2012-12-19 11:24:56 EST

It is possible that the problem is when the record is created on the server.
For example in file.js lines 68 - 72 and lines 128 - 139

Comment 7 Grant Gayed

2012-12-20 16:17:19 EST

(In reply to comment #5)
> Grant, what do you think about the fix?

Looking at the change, is the implication that the file system node is not a Directory, but it has its ChildrenLocation value set, and therefore Directory is being set to true on it invalidly?  And if so, wouldn't the problem be the mismatch between Directory==false while ChildrenLocation !== null?  Or am I missing something?

Comment 8 libing wang

2013-01-03 10:57:46 EST

(In reply to comment #7)
> (In reply to comment #5)
> > Grant, what do you think about the fix?
> 
> Looking at the change, is the implication that the file system node is not a
> Directory, but it has its ChildrenLocation value set, and therefore
> Directory is being set to true on it invalidly?  And if so, wouldn't the
> problem be the mismatch between Directory==false while ChildrenLocation !==
> null?  Or am I missing something?

Yes, we may want to change the node file service part, not the generic part.

Comment 9 libing wang

2013-01-10 16:58:07 EST

Fixed with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=6a3b0d139fd1463e35010635aa9c18bbdb8bfcc6.

Thanks Boris and Grant for the comments.

Comment 10 libing wang

2013-01-10 17:11:08 EST

There were two issues behind the scene on the node file systems:

1.When requesting for a folder's parents with the location that ends with '/', e.g. "file/lib/", we are returning /lib/ itself as the tail of the parents chain. But "file/lib" will be ok.
This is why, without the fix, if you just cd to a folder, and do pwd right away, it shows /lib/lib/ at the tail. 

2.When requesting a file meta data, the ChildrenLocation is always set ot some thing while Directory property is set to false.
I am not sure why shell page is resetting Directory to true if a nod ehas ChildrenLocation property but anyway, I set that to null to a file now.