Bug 879347 - Bundle upload hangs if the bundle file is not readable due to insufficient file system permissions
Bundle upload hangs if the bundle file is not readable due to insufficient fi...
Status: NEW
Product: JBoss Operations Network
Classification: JBoss
Component: Provisioning (Show other bugs)
JON 3.1.1,JON 3.1.2,JON 3.2,JON 3.2.1
Unspecified Unspecified
high Severity low
: ---
: JON 4.0.0
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-22 11:31 EST by bkramer
Modified: 2014-09-03 15:20 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 879350
: 879350 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description bkramer 2012-11-22 11:31:21 EST
Description of problem:

When trying to upload bundle file using JON UI, if bundle file does not have read permission set, JON UI will not timeout or fail and there will be no indication in the log file that can point to the problem. 

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

How reproducible:
Always

Steps to Reproduce:
1. create bundle file and make sure that the read permission is not set
2. attempt to upload it in JON UI
3.
  
Actual results:
JON UI will show spin icon - and it will go like that without timing out or failing.

Expected results:
JON will time out and it will show error message so that customer can correct the permissions.

Additional info:
Comment 1 John Mazzitelli 2013-05-07 15:31:28 EDT
As simple as you would think this would be, its ridiculously hard to figure out how to get this to work.

It is simple to write the code to do what we want. In this method:

  org.rhq.enterprise.gui.coregui.client.components.upload.FileUploadForm.submitForm()

we simply want to check to see if the file exists and is readable:

    // --- START BZ 879347
        } else if (!new java.io.File(value.toString()).getAbsoluteFile().canRead()) {
            String message = "Make sure the file exists and is read-accessible";
            changeIcon(iconRed, message);
            setUploadError(message);
            // note - don't even submit this definite failure            
    // --- END BZ 879347
        } else {
            changeIcon(iconLoading, MSG.common_msg_loading());
            uploadInProgress = true;
            super.submitForm();
        }

The problem is, SmartGWT doesn't want to tell us the full path of the file the user selected!!! value.toString() is returning just the name of the file with no path information - even though (in FF at least) I can see the absolute, full path of the file in the text field of the file upload component. So I know the component knows the full path, its just not telling me what it is. I tried other APIs on the component but nothing it giving me the full path. So I have no way of actually checking to see if the file is readable.

Also, I have error callbacks set up, but for some reason, the component isn't calling my error callbacks if it fails to read the file. So even that code isn't able to detect the problem and report it to the user.

So, there are roadblocks all through this that is making it impossible for me to even ask the GWT API to tell me if there is a problem so there is no way for me to avoid doing the upload if I know it will fail, nor is there a way for me to be told this problem occurred during the upload.
Comment 2 John Mazzitelli 2013-05-07 15:43:24 EDT
From the SmartGWT Javadoc:

http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/widgets/form/fields/UploadItem.html

"NOTE: Browser-specific behaviors:
while getDisplayValue() can be used to retrieve the filesystem path of the uploaded file on some browsers, different browsers will return either just the file name without path or the full path. It is plausible that some browsers may switch behavior in the future to not supply this value at all. Do not rely on this value."

This is exactly what I see with the getValue() API as well. Terrrrrrific!
Comment 3 Heiko W. Rupp 2013-08-12 07:43:46 EDT
Mazz,
can you please re-visit this?
Could we just tell that to upload to some "random" temp file? And require the (target) file name to be provided on top of that?

The REST-api now also has an upload option, where a tmp-file is created and a handle returned to the caller. Perhaps that is helpful in some way.
Comment 4 John Mazzitelli 2013-08-12 10:32:05 EDT
(In reply to Heiko W. Rupp from comment #3)
> Mazz,
> can you please re-visit this?
> Could we just tell that to upload to some "random" temp file? And require
> the (target) file name to be provided on top of that?
> 
> The REST-api now also has an upload option, where a tmp-file is created and
> a handle returned to the caller. Perhaps that is helpful in some way.

Can you explain? Are you saying to upload to a temp file and then we rename that temp file? If so, the problem isn't the target. The problem is the source. The user doesn't have read permissions on the file he's trying to upload. So the problem is occuring on the client side.
Comment 5 Heiko W. Rupp 2013-08-12 10:51:58 EDT
Ohhh. Fixing pebkac :)

This may help then: http://www.html5rocks.com/en/tutorials/file/dndfiles/#toc-monitoring-progress
Comment 7 Jay Shaughnessy 2014-02-18 13:18:34 EST
I don't think this is a solvable problem using smartgwt's UploadItem widget. There is no way to get the full path (this is not a bug, it's for security reasons) and therefore we can't check the read access.  It's unclear why the upload hangs, I would consider that a smartgwt bug although I don't see any mention of that issue in their forums.

We need to know how much effort should be expended trying to support this use case of someone trying to upload a bundle they can't physically read.

I came across this potential alternate widget: 

  http://www.moxiegroup.com/moxieapps/gwt-uploader/

But it does not in the public maven repos.  So even if it worked for us we'd have to drop it in our private repo.  I don't think we should work on a replacement unless we determine this is really necessary.  Even if we do, it may not pan out.

Asking for re-triage from GSS...
Comment 9 Larry O'Leary 2014-02-27 11:00:13 EST
Moved to 3.3 as this is a non critical issue.

Although this is a bug in the client side code, the file a user wants to upload must be readable by the user who is attempting to upload it.

This needs to be investigated further to see how we can fix this.
Comment 10 Jay Shaughnessy 2014-09-03 15:20:03 EDT
There is no more to add than what is above, this is either unsolvable or may require a lot of work (and maybe still doesn't work).  Pushing to JON 4 and maybe  a different GUI technology.

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