Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #212382 comment 16 +++ Connecting to an AS/400 (System i) machine with the new parser from bug 212382 that sends "site namefmt 1" to remote on connect, I could see the files/folders right under the "/" directory in. But I could not expand any folders under it. I got this error: Folder /home is not readable. Cannot expand. But I do have enough authority on the system to access to home and all its sub folders. The console doesn't show any extra output when expanding the folder, so it looks like either the children of /home are not correctly parsed or the new list query is not made at all for any reason. It looks like we'll need to debug this.
I did some debugging of this, and that is what I found. The reason the no ftp command is issued to the host when I expanded the home directory is that it is considered to be not readable. To decide if a FTPHostFile _canRead, we check this: _canRead = ftpFile.hasPermission(FTPFile.USER_ACCESS, FTPFile.READ_PERMISSION); But in this case, for _permissions array (3 * 3 array) has all its array elements as "false". That is why it is not considered to be readable. The reason for all "false" in the _permissions array is that the OS400FTPEntryParser#parseFTPEntry() method did not populate it. But other FTPEntryPasers, like UnixFTPEntryParser, its parseFTPEntry() method actually updates this permission array. The following is the code for UnixFTPEntryParser#parseFTPEntry() to update this permission array. int g = 4; for (int access = 0; access < 3; access++, g += 4) { // Use != '-' to avoid having to check for suid and sticky bits file.setPermission(access, FTPFile.READ_PERMISSION, (!group(g).equals("-"))); file.setPermission(access, FTPFile.WRITE_PERMISSION, (!group(g + 1).equals("-"))); String execPerm = group(g + 2); if (!execPerm.equals("-") && !Character.isUpperCase(execPerm.charAt(0))) { file.setPermission(access, FTPFile.EXECUTE_PERMISSION, true); } else { file.setPermission(access, FTPFile.EXECUTE_PERMISSION, false); } }
Thanks for the investigation Xuan. When I'm not mistaken, we already made a similar workaround for VMS some time ago, where we'd simply mark all entries readable since the information about r/w status was not contained in the FTP listing. Seem like we'd have to apply a similar workaround here. What's important to know for me now, is whether the r/w information _would_ be available in the FTP "dir" output and Commons Net doesn't parse it; or, whether the information isn't ever contained. Can you check this please, running "ftp yourhost" on command-line followed by "cd /home ; dir" commands ?
This is what I found: 230 XUAN logged on. ftp> cd /home 250-NAMEFMT set to 1. 250 "/home" is current directory. ftp> dir 200 PORT subcommand request successful. 125 List started. JSHMOK 8192 03/08/26 16:47:35 *DIR vabld/ XUAN 8192 05/02/23 17:00:52 *DIR ew512test_bak/ So it dose not seems have the permission info available for the "dir" command.
Thanks Xuan. Can you also try a "dir" command on commandline without the "set namefmt 1"? Also, I'd like to see output of quote feat command, thanks
If I don't specify the "set namefmt 1", it only shows the traditional iseries library objects. And this is the example of it: XUAN 380928 06/02/08 14:52:38 *FILE B5CORVWMAP XUAN 77824 06/02/28 11:09:51 *FILE CRTPHPGMS XUAN 57344 05/02/01 11:10:53 *FILE ENDDBGSVR XUAN 139264 05/02/01 11:05:34 *FILE ENSVR And the result of "quote feat" command is: ftp> quote feat 211-Feature listing follows: AUTH TLS PBSZ PROT 211 End of feature listing.
Thanks Xuan. Apparently OS/400 just doesn't have any permission bits available anyways, so the parser should expect all files to be readable by default. Javier: Actually I think the best solution would be to assume all files readable and writable by default (in the FTPHostFile) unless it's overridden by the FTP parser. Can you get this fixed? I'm setting target milestone M7 since we now understand what the problem is. M7 is the feature freeze and AS/400 FTP support would be a new feature.
Just some FYI... I ran the qshell support in our product, and I could see the permission bits been displayed when running "ls -l" command. It is probably just the FTP.
can you try DIR -l in FTP, just for a test?
Created attachment 95083 [details] patch setting file with r+w permissions by default Since the file permissions are initialised and set as part of org.apache.commons.net, we could provide an extension of the parser that sets the USER file permissions to read+write, RSEOS400FTPEntryParser, instead of using the default implementation. It would similar as the solution we had for WindowsNT. What do you think about it ?
Patch looks good to me. Please add a Copyright Header and go ahead.
Ah yes, and of course you'll need to if (f!=null) { f.setPermission(...) }
I applied the patch, and also added the if (f!=null) { command Martin recommanded, and it works must better now. I was able to expand the IFS file subsystem, and open some files (I tried a couple .txt file). I actually got a NPE for a file (not sure why) if I did not add "f != null".
One more comment, "dir -l" is illegal in FTP of the iseries I tried.
Created attachment 95108 [details] patch checking in file is null and with Copyright header Please better use this patch that checks if the returned object is null and contains the required Copyright header information
Applied patch
Comment on attachment 95108 [details] patch checking in file is null and with Copyright header Marking patch iplog- since Javier was committer since 2006 already: http://dev.eclipse.org/mhonarc/lists/dsdp-tm-dev/msg00375.html
