Normal directory structure tree handling

Discuss Shareaza features.
Forum rules
Home | Wiki | Rules

Normal directory structure tree handling

Postby octagram-3 » 14 Feb 2010 08:33

I can't download directories from remote hosts. When I browse a host and right click a directory, "download" options are disabled in the context menus of directories. Directories are also not present on the right pane. When I open a folder in Explorer of Finder, both files and directories are present on the right pane. In Shareaza, directories are only to the left, and they are not downloadable.

I have found just one way to download the whole directory: select all the subdirectories (or collapse the directory and select it) and then select all the files to the right and download them. However, the directory structure is lost completely! It reminds me of the times when not quite every zip archiver could handle directory structures. I had to manually restore the directory tree integrity!

Shareaza's metadata handling is superior to GreyLink DC++. GreyLink is the only DC client I know that handles metadata. User must install MediaInfo.dll into GreyLink. User must also allow mediainfo requests (they are disabled by default). Metadata are being queried on demand for a single file. They do not live in database. A very weak metadata support compared to Shareaza.

However, Shareaza is very weak at SUBJ. Current behaviour is awful. I can't say that DC developers got things right for the first time. "Getting things right" means that I download essentially the same bits of information that uploader has shared. Like FTP.

How to screw things up?

For instance, ApexDC++ has two options for dealing with already shared files: do not download or download again. Pick your poison. Happily enough, GreyLink has an option to copy files from the share. This way I won't miss msvbvm.dll or instmsiW.exe or gdiplus.dll in the downloaded directory structure. And I won't download every matching file again. Another opportunity to screw things up is incomplete filelists. Advanced Direct Connect defines a query of directory list. It works faster than downloading the whole filelist. ApexDC++ downloads directory filelists on demand when you select it in the left pane. However, when I choose to download a directory with unexplored subdirectories, ApexDC++ leaves them empty. Unpleasant surprise! Unhappily, GreyLink haven't got this thing right yet. It also leaves empty directories.

From this point of view Shareaza sucks even more than ApexDC++.
octagram-3
 
Posts: 9
Joined: 14 Feb 2010 04:11

Re: Normal directory structure tree handling

Postby diztrancer » 14 Feb 2010 14:29

This ridiculous. DirectConnect and Shareaza have totally different approach to file sharing. DC is community based scene -releases oriented community, where users are responsible of correct file/directory naming. They even can be banned from hub for wrong/misleading naming or for renaming scene releases. In Shareaza no rules at all. Normal people share releases in one compressed file, not so intellectually gifted - share directories :(
User avatar
diztrancer
 
Posts: 222
Joined: 13 Jun 2009 15:41
Location: Ukraine

Re: Normal directory structure tree handling

Postby ailurophobe » 14 Feb 2010 15:35

In Gnutella and ED2K based clients people use collections to share groups of files. In BT batch torrents. Often archives are used as well for this purpose. Directory structure is shown in browse because it makes browsing easier by grouping related files together, but the assumption is that different users have different ways to organize their file hierarchies and retaining the directory structure would be useless to downloaders. Almost always this is true. (In networks supported by Shareaza, it is different in DC, I'll agree to that.)
ailurophobe
 
Posts: 709
Joined: 11 Nov 2009 05:25

Re: Normal directory structure tree handling

Postby octagram-3 » 15 Feb 2010 09:47

octagram-3
 
Posts: 9
Joined: 14 Feb 2010 04:11

Re: Normal directory structure tree handling

Postby ailurophobe » 16 Feb 2010 05:02

If the user employs a folder naming scheme consistent enough to be useful, they likely also name files consistently. The primary source of file information is a proper file name. I am sure there are cases where somebody has useful folder hierarchy and useless file names, but it should be pretty rare. As in rare enough to be avoidable without great loss. File names are useful over search (commonly used), folder names just over browse (rarely used). So file names should always stay as much more reliable source of info than folder names.

I agree, most do I think, that making collections should be more obvious. A context menu item for folders, drag and drop to add files to a collection and so on. But people just don't seem to be very interested...

EDIT: Just to be clear. Not like I oppose being able to download folders. I just don't see much of a benefit. And if you can't convince me, convincing someone to code this is unlikely. (Not because it is somehow up to me, but simply because it is not my work we are talking about.) As you may know we have a bit of a developer shortage, and many more useful features on the to do list.
ailurophobe
 
Posts: 709
Joined: 11 Nov 2009 05:25

Re: Normal directory structure tree handling

Postby octagram-3 » 16 Feb 2010 15:03

octagram-3
 
Posts: 9
Joined: 14 Feb 2010 04:11

Re: Normal directory structure tree handling

Postby ailurophobe » 21 Feb 2010 00:47

Good example. I see what you mean now. In my defense, everyone I know shares albums as RAR files. It just works better.
ailurophobe
 
Posts: 709
Joined: 11 Nov 2009 05:25


Return to Features

Who is online

Users browsing this forum: No registered users and 0 guests

cron