I noticed that when i download for example McRip Win7 x64 all the downloaded files had their modify dates changed to current date. I would like if WTK would respect and preserve file dates as they appear on the server.

I think this is virtually impossible, as the file is downloaded and ''created'' on your local disk.

 

If you worry about the source & data integrity of the files downloaded, there are more advanced tools for this out there, as for example MD5 readers.

I think this is virtually impossible, as the file is downloaded and ''created'' on your local disk.

 

If you worry about the source & data integrity of the files downloaded, there are more advanced tools for this out there, as for example MD5 readers.

 

While I don't disagree with your second point, it should be possible to "respect and preserve the file dates as they appear on the server", since other programs such as FileZilla are able to do this with ease.  I agree that it would be a good idea if Win Toolkit was able to do this as well.

 

Cheers and Regards

Yes, I'm sure this is possible. This is like when you download your photos from the camera the program sets the file date to shooting date (preserve the original source date) not current date.

Since 1.5 is in Beta it would be a good time to include this. Its certainly possible as WDI dev also added this: http://forums.mydigitallife.info/threads/36058-Windows-Download-Integrator

WDI along with WTK are the only programs allowed to download from McRip server.

It is possible, but what are the reasons for doing this?

The main reason is that with the proper date i can create a changelog about what was added/removed/renewed compared to last month. I maintain a separate update pack that is based on McRip-s updates.

But since dates are all the same then i have no clue what was updated. I could use the changelog that McRip provides himself but then i would have to sync that and my own (easier said than done).

I don't want to be on the negative side, but I also keep a changelog of what's new in McRip's changelog, especially now that McRip is busy, as you can see here fo ex., and I NEVER look out for the date of a hotfix. In the ''worst'' case, I look for the digital signature's date, but especially for the MD5.

 

Also Lego seems a little busy lately, and there are more useful things (in my opinion) that can be implemented in his app before your request, so I vote ''against'' it for the near future. Again, sorry, I hope you won't get upset, but this request seems to me more on the whim-side than the useful-side.

Edited April 23, 201311 yr by RicaNeaga

Sorry, RicaNeaga, but I respectfully disagree.  I understand your points, and agree that something stronger than just a date should be used to confirm file changes, but the date can be a very easy "first pass" check.  I also do not think that this change will take Lego much time to implement.  If I am wrong, then I will agree with your point about Lego having more important things to implement.

 

Cheers and Regards

why if you move the program to different directory

 

the programe keep download updates to the old folder directory !!

1) Where was the program originally?

2) Where was the original updates download folder located?

3) Where did you move the program?

4) Where did you expect the updates download folder to move to?

5) What did you do to try to get it to move where you wanted?

 

Cheers and Regards

thanks for replay

the folder was on desktop and iam download some updates

then iam move the program to another directory and start download updates

the program keep send updates to old directory folder on desktop

i think its because the setting text file with the program when you start the program in first time keep download old directory what ever you move the all program folder keep download update to old directory

iam solve the problem iam delete the setting text file and program automatic create new one with correct setting

Correct.  Once the setting file has set the download location, it is stored as an absolute location, not a relative location, so moving the program itself will not change things.  Letting the program recreate the settings file, or manually editing it, "fixes" things.  Glad you got it figured out.

 

Cheers and Regards

I don't want to be on the negative side, but I also keep a changelog of what's new in McRip's changelog, especially now that McRip is busy, as you can see here fo ex., and I NEVER look out for the date of a hotfix. In the ''worst'' case, I look for the digital signature's date, but especially for the MD5.

 

Also Lego seems a little busy lately, and there are more useful things (in my opinion) that can be implemented in his app before your request, so I vote ''against'' it for the near future. Again, sorry, I hope you won't get upset, but this request seems to me more on the whim-side than the useful-side.

Ok i can understand about not findinding it relevalt or much use to you but voting against?

Makes no sense. Either it will be implemented or it will not. Theres no "downvote" option here imho.