|
[udanax@a51066 hadoop]# bin/hadoop dfs -du / Found 4 items 11358 hdfs://localhost:9000/LICENSE.txt 1366 hdfs://localhost:9000/README.txt 0 hdfs://localhost:9000/home 0 hdfs://localhost:9000/user [udanax@a51066 hadoop]# bin/hadoop dfs -ls Found 5 items 1 11358 2008-04-10 18:27 -rw-r--r-- root supergroup /user/root/LICENSE.txt 1 101 2008-04-10 18:27 -rw-r--r-- root supergroup /user/root/NOTICE.txt 1 1366 2008-04-10 18:26 -rw-r--r-- root supergroup /user/root/README.txt 1 831954 2008-04-10 18:41 -rw-r--r-- root supergroup /user/root/hadoop-0.18.0-dev-test.jar 0 2008-04-10 18:26 drwxr-xr-x root supergroup /user/root/logs [udanax@a51066 hadoop]# Doesn't it need a test case?
If so, i'll submit this patch. +0.7
I think this is good as a first step in improving the formatting of ls. There are 3 cases when formatting brakes
2 168 2007-10-09 20:21 -rw-rw-rw- shv supergroup /README.txt 0 2008-04-09 18:47 drwxr-xr-x administrator supergroup /conf 3 12345678 2008-04-09 18:46 -rw-r--r-- shv supergroup /conf/.svn/README.txt 3 1234567 2008-04-09 18:47 -rw-r--r-- shv supergroup /conf/.svn/dir-prop-base 3 90 2008-04-09 18:46 -rw-r--r-- shv user /conf/.svn/dir-wcprops 3 9012345 2008-04-09 18:47 -rw-r--r-- shv supergroup /conf/.svn/dir-props The first one is going to be very common, since we expect large files and design for it. And we should fix it. Dynamically calculating column widths is probably the next logical improvement step, which belongs to a different issue. We should mark this issue as an incomatible change. This v02.patch include the AutoFit (by using in-memory) as describe below.
[root@udanax hadoop]# bin/hadoop dfs -du Found 2 items 11358 hdfs://localhost:9000/user/root/LICENSE.txt 1366 hdfs://localhost:9000/user/root/udanax [root@udanax hadoop]# bin/hadoop dfs -ls Found 2 items 1 11358 2008-04-15 10:53 -rw-r--r-- udanax supergroup /user/root/LICENSE.txt 0 2008-04-15 12:54 drwxr-xr-x root supergroup /user/root/udanax [root@udanax hadoop]# BTW, what does Incompatible change" mean? and What should i do? when a lot of files are exist, v02.patch seems problematic.
Checking incompatible change.
In your code could you please set initial values to
int maxReplication = 3, maxLen = 10, maxOwner = 0,maxGroup = 0;
This should work for most files. Thank you for your review, Fixed them.
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12380230/2865_v04.patch  against trunk revision 645773. @author +1. The patch does not contain any @author tags. tests included -1. The patch doesn't appear to include any new or modified tests. javadoc +1. The javadoc tool did not generate any warning messages. javac +1. The applied patch does not generate any new javac compiler warnings. release audit +1. The applied patch does not generate any new release audit warnings. findbugs +1. The patch does not introduce any new Findbugs warnings. core tests +1. The patch passed core unit tests. contrib tests +1. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/2246/testReport/ This message is automatically generated. I just committed this. Thank you Edward.
Integrated in Hadoop-trunk #463 (See http://hudson.zones.apache.org/hudson/job/Hadoop-trunk/463/
) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
FsShell.ls() should print file attributes first then the path name.
Some even failed when we just added a timestamp...