[smbscan] Leave only 'reverse' output method

[GoogleCodeExporter]

Removing other output methods from dt.c will
1. reduce source code size significantly
2. allow dt_go_sibling_or_parent() to be implemented without a loop
3. allow a tree walker procedure to remove nodes left by going to it's
sibling (now we free() node's childs when leaving, not the node itself)

Leave this issue open until we have other parts of uguu ready.

Original issue reported on code.google.com by ruslan.savchenko on 3 Jan 2010 at 11:35

[GoogleCodeExporter]

Rejected.
Instead, list of childs should be splitted into two lists: files and 
subdirectories.

Original comment by ruslan.savchenko on 5 Jan 2010 at 11:58

[GoogleCodeExporter]

Instead of -f <method> argument we should use witches:
-f  - full output (simplified if -f is not given)
-r  - reverse output (directories are printed after their contents)
-s  - contents of each directory is sorted alphabetically (subdirs first, files
afterwards)
-p  - ping mode. Try to connect and get a bit of contents (to be used by pinger)

Original comment by ruslan.savchenko on 6 Jan 2010 at 1:10

[GoogleCodeExporter]

Here is the alternative suggestion:

-mf : test human-friendly output, like
/ <DIR>
/some_dir <DIR>
/some_dir/some_file file_size
/some_dir/big_file size_megabytesM
...

-ms : script-friendly output, for importing into db
-mp : ping mode

File lists should be sorted alphabetically, but directories might come after 
all the
files (but alphabetical order through directories should be maintained). Later 
we may
resort them with "ORDER BY (type==1), id", where type=1 for directories and id 
is
auto-increment key.

Original comment by radist...@gmail.com on 6 Jan 2010 at 6:04

[GoogleCodeExporter]

Why do you need that 'm' in an option string?
And why not to list directories before files? Doing so would save us one level 
of
ordering parameters

Original comment by ruslan.savchenko on 6 Jan 2010 at 6:33

[GoogleCodeExporter]

one more question: do you really want not to print total size for directories in
human-readable mode?

Original comment by ruslan.savchenko on 6 Jan 2010 at 6:34

[GoogleCodeExporter]

> Why do you need that 'm' in an option string?
Just for saving -?-like parameter letters (scanners could introduce some 
specific
parameters, so the general ones shouldn't use so many letters). Another option 
is to
make script-friendly output as default. Also "-p" option could be used to 
specify the
port (ftp).
However, we may allocate all the lowercase letters for general options and 
uppercase
letters for the scanner-specific options, and so "m" addition will not be 
required.

> And why not to list directories before files? Doing so would save us one 
level of
ordering parameters
Actually, we don't need it if scanners will output the id_within_share for all
objects. So ordering by id_within_share is enough yet directories will be 
passed to
output later then files.

> one more question: do you really want not to print total size for directories 
in
human-readable mode?
well... we can introduce another option (i.e. -md, or )

Original comment by radist...@gmail.com on 6 Jan 2010 at 7:28

[GoogleCodeExporter]

>Just for saving -?-like parameter letters (scanners could introduce some 
specific
parameters, so the general ones shouldn't use so many letters)
Oh no, I don't plan implementing anything like gtk_init() which parses argv for
options it can recognize. I would like to have dt_param structure and pass it 
to dt
interface functions. How to allocate options -  it is up to scanner themselves.
And don't think I'll agree with getopt()-incompatible argument naming style. I 
won't
use getopt(), but having some strange parameter naming is nonsense.

>well... we can introduce another option (i.e. -md, or )
Sure we can. But I don't think it is necessary to care about functionality 
nobody
will ever use.

Original comment by ruslan.savchenko on 6 Jan 2010 at 7:49

[GoogleCodeExporter]

> Sure we can. But I don't think it is necessary to care about functionality 
nobody
will ever use.
You're right. Also, directory sizes in testing human-readable mode is the same
functionality.

By the way, as for ping mode: whether scanner should accept multiple hosts (list
could be passed via stdin), or online checking should be performed by script to 
avoid
creation of the large number of processes.

Original comment by radist...@gmail.com on 6 Jan 2010 at 8:33

[GoogleCodeExporter]

>Also, directory sizes in testing human-readable mode is the same
functionality.
No. Human-readable mode is for debugging and I thing one would like to have full
information when debugging.

>whether scanner should accept multiple hosts
Do not want it now. If we really happen to need this (in case of a huge 
performance
boost which I don't believe would happen) it could be fixed easily.

Original comment by ruslan.savchenko on 6 Jan 2010 at 8:46

[GoogleCodeExporter]

More on scanner output: Revision 7944701918

Original comment by ruslan.savchenko on 8 Jan 2010 at 5:01

[GoogleCodeExporter]

All great ideas discarded. Simplicity wins.

Original comment by ruslan.savchenko on 21 Jan 2010 at 12:12

• Changed state: Fixed