File creation date attribute in filelists

[Sergeo7 1]

This is my "most needed feature" for the time being. It'll be very useful to have possibility of sorting files/dirs in filelists by date and time of creation and will help to create autonomous bot of new releases.

PS: Since all filelists are in XML, I don't think that it'll affect clients compatibility.

[Sergeo7 1]

Don't you think so? With this DC can almost fully replace ftp server.

[Zlobomir 3]

Not bad, but not sure about implementation. Awaiting dev's comment.

[Greg 0]

An "Added Date" field may be worthwhile, I think something like this was proposed in the past but pretty much rejected due to the extra filesize it would add to filelists. As time goes on this should be less and less of an arguement. Well, as I say I'm for it, but I'll await a comment from a developer.

[Crise 26]

Well if we added such field, people could tell when the file list is apex made and when not, so emulation would break effectively...

[Zlobomir 3]

Just not include this field when emulating.

[Big Muscle 1]

Just not include this field when emulating.

it's not possible, because filelist is global but emulation is hub dependent.

also I am against this feature because it will increase filelist size rapidly.

[Greg 0]

The emulation issue kind of makes it a deal breaker. I would be willing to sacrifise being able to emulate DC++, but plenty of other people wouldn't.

[dmvn 0]

it's not possible, because filelist is global but emulation is hub dependent.

also I am against this feature because it will increase filelist size rapidly.

I agree with Greg: somebody who wants to use this feature, *will* sacrifice DC++ compatibility. This option must force disabling 'dc++ compat' checkbox, and vice versa. Then people will be able to make their own choice.

Uff, filelist size... This field is the UNIX timestamp... So it's 10-15 bytes per shared file... Not so much, especially for modern HDDs and LANs.

Anyway, sounds good. For it.

[Big Muscle 1]

Uff, filelist size... This field is the UNIX timestamp... So it's 10-15 bytes per shared file... Not so much, especially for modern HDDs and LANs.

When you have 20000 files in your filelist, it means file increase about 300 kB and it's too much! not everyone has LAN! Filelist is something which must be downloaded as fast as possible.

[Sergeo7 1]

Maybe it's possible to add this feauture and option to enable/disable it so users can decide whether they want to give up DC-emulation and increase filelist size to have the good feauture enabled?

It's a fact that not all people have a LANs now, but thouse who have, often using DC in LAN only.

[Zlobomir 3]

It is probably possible to generate two filelists - one with date field, one w/o it. And depending on emulation/network speed, using the appropriate one. Right, this will require more than 2x space on own HDD.

[Sergeo7 1]

It's a variant. And with this "connection" field can finally be used for something. (But then connection setting must be hub-based for the whole idea to work at capacity.)

[Big Muscle 1]

Maybe it's possible to add this feauture and option to enable/disable it so users can decide whether they want to give up DC-emulation and increase filelist size to have the good feauture enabled?

userlist's owner doesn't download this filelist and downloader can't select

[Sergeo7 1]

Don't understand why downloader need to select it? As I think, we had been talking about selecting proper filelist on uploader's side, depending on downloader's speed.

If the feature is disabled then all of the functionality ignored, if enabled - we must globally disable DC-emulation and create second filelist with dates. This filelist we will upload only to users who has, for example, >5 in connection field.

[Big Muscle 1]

Don't understand why downloader need to select it?

Because it's downloader who selects to download file list and must wait for it!

When I want to download someone's filelist, I want to download immediately and not to wait until it downloads some large file which contains for-me-useless information.

As I think, we had been talking about selecting proper filelist on uploader's side, depending on downloader's speed.

there's no possibility to detect downloader's speed.

[Sergeo7 1]

We do know what downloader set in "Line speed" and it's on his conscience if it's true or just random.

And is it truly impossible to detect if client can send filelist with dates? How about adding feature to Supports/SUP list to make it visible for downloader?

[Toecutter 0]

This is my "most needed feature" for the time being. It'll be very useful to have possibility of sorting files/dirs in filelists by date and time of creation and will help to create autonomous bot of new releases.

PS: Since all filelists are in XML, I don't think that it'll affect clients compatibility.

Hmmm...

Did the thread go off topic?

The original question related to the creation date of a file.

This is part of the files meta data but will not neccesarily carry over with the file.

i.e. If I download a file from anothjer user I'm not guaranteed to show the same date of creation as part of the files meta data (look yourselves at the properties of files you have downloaded).

Therefore, a bot would not be able to read an original creation date.

Or have I missed the point?

My 2p

Toecutter

[Zlobomir 3]

I just thought of small http server in Apex, just for filelist download, I could use HFS f. ex right away. In this way slower users could select among not only two, but many filelists to download.

[Sergeo7 1]

i.e. If I download a file from anothjer user I'm not guaranteed to show the same date of creation as part of the files meta data (look yourselves at the properties of files you have downloaded).

Therefore, a bot would not be able to read an original creation date.

It's just a matter of agreement how programs should treat a file attributes. But in fact you miss the point. I had been talking about getting this data from uploader's side, so downloader can sort file-list by date or use some kind of date/time analysis, e.g. for downloading newest files in share.

For example someone have a folder with 1000 files you like, from which you downloaded all. Next time you go to the same folder and see 1200 files. Assuming that previous files you had deleted or they are not in your share now, how can you know which files you need? If there is a date of creation you can just sort by it and see if there are files created approximately after last visit and download them. At present for such task you need to keep/memorize previous files - which is really inconvenient.

I just thought of small http server in Apex, just for filelist download, I could use HFS f. ex right away. In this way slower users could select among not only two, but many filelists to download.

Or simply add an additional protocol command, that'll provide file-lists list ^__^

To go even further client can have support for several metadata sending commands for date/time, file comments, ratings, MP3-tags, attributes or whatever. ^____^'

[Satan 1]

I'm against anything that increases file list size. At present. My file list is 450Kb and my share is 1.10Tb.

I downloaded a file list at the weekend which was 4.5MB for a 600Gb share. So many people already have oversized lists, simply because they cant sort out decent folders for their shares. This feature would give these n00b's even more bulk!!!

Another thing, I have 7 HDD's, so if this feature was implemented and I moved a folder from say Share1 to Share3, would this not re-assemble all the date's shared into todays date, making the feature useless.....why do people need to know when you shared the file?

[Sergeo7 1]

1) Reading file dates is much much faster process than hashing so, if you move files, updating this property won't take a long time.

2) We have discussed possibility to disble feature for those who don't need it up to now (maybe even disable by default).

3) It's NOT time when you shared the file but the time when it was created on HDD these are a way too different things.

4) Some file managers allow preservation of creation date upon moving. Plus moving some persistent files over a HDDs isn't frequent event.

[Satan 1]

3) It's NOT time when you shared the file but the time when it was created on HDD these are a way too different things.

Those will be the same, when you move a file from HDD to HDD DC reshares it, hence it will say the same thing as windows.

Also, windows update when files are moved.

[Toecutter 0]

It's just a matter of agreement how programs should treat a file attributes. But in fact you miss the point. I had been talking about getting this data from uploader's side, so downloader can sort file-list by date or use some kind of date/time analysis, e.g. for downloading newest files in share.

For example someone have a folder with 1000 files you like, from which you downloaded all. Next time you go to the same folder and see 1200 files. Assuming that previous files you had deleted or they are not in your share now, how can you know which files you need? If there is a date of creation you can just sort by it and see if there are files created approximately after last visit and download them. At present for such task you need to keep/memorize previous files - which is really inconvenient.

Or simply add an additional protocol command, that'll provide file-lists list ^__^

To go even further client can have support for several metadata sending commands for date/time, file comments, ratings, MP3-tags, attributes or whatever. ^____^'

I just had another thought on this in light of what you say above.

If there was a facility to keep the users filelist (like say class them as a 'seed' user), all you would neet to do is download the latest filelist and carry out a compare between the two. This would produce an exception list for you.

You could then select from the exception list and this would then be kept as the seed users list for the next compare.

another 2p worth

[patch1 0]

It's just a matter of agreement how programs should treat a file attributes. But in fact you miss the point. I had been talking about getting this data from uploader's side, so downloader can sort file-list by date or use some kind of date/time analysis, e.g. for downloading newest files in share.

For example someone have a folder with 1000 files you like, from which you downloaded all. Next time you go to the same folder and see 1200 files. Assuming that previous files you had deleted or they are not in your share now, how can you know which files you need? If there is a date of creation you can just sort by it and see if there are files created approximately after last visit and download them. At present for such task you need to keep/memorize previous files - which is really inconvenient.

What you are trying to do is see what is new in the file list since previous times you looked at that user.

There is another way of getting this display without modifying the file list download.

ApexDC in fact already has the data it needs to tell you. It is contained in the file lists you downloaded in the past.

What ApexDC needs to do is keep the last, say 10 (a settable parameter) filelists from each user.

Then when you are browsing someones file list, ApexDC could have a drop down menu to select "New files since" --> dates/times of old file lists.

ApexDC could then high lite folders containing new files. Alternatively it could subtract the old file list, automating the process described here http://forums.apexdc.net/index.php?showtopic=1717&hl=

If this was based on the hash value it would be independent of changed directories & file names