modified time of files

[alexw]

Hi,

Is there a way to ask qBittorrent to set the "modified time" of the files it downloads to the current datetime instead of the original time?

Cheers

[ciaobaby]

Nope.

Mainly because the files are NOT being 'modified' OR 'created' at that point in time, they are merely being assembled in the original form, piece by piece and that is [b[literally[/b] piece by piece.

[alexw]

I know how they are assembled, but qBittorrent sets the "modified" time of the file to the date stored in the torrent (e.g. Dec 2007). I'd like it to set the "modified" date to the current system date.

[ciaobaby]

I know how they are assembled,

1/ You may 'know' but you obviously do not fully understand what that really means.

but qBittorrent sets the "modified" time of the file to the date stored in the torrent (e.g. Dec 2007). 

Nope qbittorrent does NOTHING with the dates, the dates are whatever dates are stored in the structure of the payload.

I'd like it to set the "modified" date to the current system date.

Well sorry; ... but you can't, because if it DID, the torrent payload would be irrevocably changed and thus 'broken' relative  to the hash sums in the meta data. see point 1/ regarding not really understanding what actually happens during the payload re-construction.

There are NO "date changing" events occurring during the process, it is a 'cloning' process not a creation process.

[alexw]

[quote="ciaobaby"]
1/ You may 'know' but you obviously do not fully understand what that really means.

Nope qbittorrent does NOTHING with the dates, the dates are whatever dates are stored in the structure of the payload.

Well sorry; ... but you can't, because if it DID, the torrent payload would be irrevocably changed and thus 'broken' relative  to the hash sums in the meta data. see point 1/ regarding not really understanding what actually happens during the payload re-construction.

There are NO "date changing" events occurring during the process, it is a 'cloning' process not a creation process.[/quote]

Again, I know how the process works, despite your adamant (and very friendly) assumptions about my intelligence/insight. Again, I'd like an option for qBittorrent to set the "modified" date to the current system date once it finishes the download. That does not invalidate anything, but before you reply again (*) please run the following simple experiment:

- Wait for a download to finish in qBittorrent which most likely is seeding it at this time (unless you're a leecher)
- then change the file's "modified" date yourself to something different
- then go back to qBittorrent and force a recheck on the torrent
- you'll notice it checks out fine and it continues to seed it, and that the "modified" date is not set back to the torrent's specified date
- then try to add again the original torrent and you'll see that qBittorrent recognizes it's already in the list.
- you may restart qBittorrent too if you wish.

The the torrent is the same, the file is valid, but it has a different modified date. I'd like qBittorrent to spare me the manual date change after it's done downloading.

(*) Perhaps don't. I'd very much appreciate a reply from a dev about this. If there is no way currently, could it please be considered for a future version?

Alex.

p.s. This is off-topic, but it may help you better understand some things: any new file (including sparse ones) created by the OS by default have the create,accessed,modified dates all equal to the current system date. A system call is needed to change the modified date. qBittorrent creates new files when a torrent is added, sparse or not, then fills them in as blocks are downloaded. What I want does not affect the assembly process (I'm changing the date after assembly is done).

[alexw]

Actually, there is no file date stored in the metadata. Changing the modified/accessed/created date of files invalidates nothing. qBittorrent actually does create new files using the current system date at the time the torrent was added, so something else must have happened in my case when I saw files dating to 2007 and 2009.

A feature request for the dev: add an option so that the "modified" date are set to the date/time the file finished download (if it ever does). It can stay equal to the created date while it's downloading, but set at the end. This could be one of the advanced options.

[ciaobaby]

Actually, there is no file date stored in the metadata.

OF course there isn't. ... ... ... The dates are PART OF THE PAYLOAD!

It can stay equal to the created date while it's downloading, but set at the end. This could be one of the advanced options.

Which bit of "it is impossible with the BitTorrent protocol" are you not understanding?

Now! Don't make me get REALLY patronising, because believe you me ... If I do, You will know that your intelligence [or my consideration of the lack of intelligence] HAS been well and truly  insulted.

So here are the salient points;

The bittorrent protocol does NOT use 'FILES', it uses blocks of data that your disk filing system 'understands' as files and folders and the 'dates' are embedded in that block, or blocks of data.

It does NOT download files.

It does NOT create files for the payload.

It does NOT modify files in the payload.

And there is absolutely NO WAY that qbitorrent or libtorrent which handles the payload, CAN change the modified date of ANYTHING in the payload. It DOES NOT 'know' how to, there is NO mechanism in libtorrent to create or modify files IN THE PAYLOAD.

[alexw]

Actually, there is no file date stored in the metadata.

OF course there isn't. ... ... ... The dates are PART OF THE PAYLOAD!

It can stay equal to the created date while it's downloading, but set at the end. This could be one of the advanced options.

Which bit of "it is impossible with the BitTorrent protocol" are you not understanding?

Now! Don't make me get REALLY patronising, because believe you me ... If I do, You will know that your intelligence [or my consideration of the lack of intelligence] HAS been well and truly  insulted.

So here are the salient points;

The bittorrent protocol does NOT use 'FILES', it uses blocks of data that your disk filing system 'understands' as files and folders and the 'dates' are embedded in that block, or blocks of data.

It does NOT download files.

It does NOT create files for the payload.

It does NOT modify files in the payload.

And there is absolutely NO WAY that qbitorrent or libtorrent which handles the payload, CAN change the modified date of ANYTHING in the payload. It DOES NOT 'know' how to, there is NO mechanism in libtorrent to create or modify files IN THE PAYLOAD.

@cioababy, you continue to miss the point and nobody cares about you getting "REALLY patronizing", nor will they feel "truly insulted" by you for that matter. Save your energy, kid.

For the devs (i.e. that excludes you, @ciaobaby): Would you please consider adding an (advanced) option so that after qBittorrent creates the sparse/pre-allocated files and finishes the download, at that point to set the "modified date" of all downloaded files and dirs to the current system date? The created date would reflect the time the torrent was added, while the modified date would reflect the time the torrent finished (I have other usages too, that have to do with library management of various media).

[sledgehammer_999]

I'll leave all the bickering aside and I'll answer to the request:
No I am not too keen in adding such a feature. I feel that it will not be useful to most of the users out there while it will contribute to feature bloat of the program.

[alexw]

Thanks for replying. I'm thinking of forking qB on github and having a stab at it. maybe you'll consider it then.

However, technically speaking "last modified" datetime should reflect when the file was last written to, which would be when the file finished downloading ... could I convince you to make this the default behaviour instead of adding an option for it? ... I take your point about bloat.

[sledgehammer_999]

You should check with libtorrent first.
Theoretically it should increment the timestamps each time it writes a piece of data into a (partial)file. Or the OS should do this automatically already.
Thus this may be a libtorrent bug.

[alexw]

Indeed, and I was also expecting the "last modified" date to increment with each write, but I thought qBittorrent intentionally sets it back (which is why I posted here).

It could be linked to the files being created as sparse. I'll switch to pre-allocation to see if it does the same and will report if not.

EDIT: Yes, it is caused by using sparse files. I just switched to pre-allocation and downloaded a torrent, and the "modified" date of the files is correctly set to when the torrent finished downloading, while the "created" date was left to when the file was created (when torrent was added). I guess this should be reported to libtorrent then so they can fix it for sparse files as well.

[sledgehammer_999]

@alexw there's probably a problem with your OS.
I just downloaded a single-file torrent under Windows XP on a HDD (not SSD) and the file timestamps had today's timestamps. And the modified date kept updating until the file was fully written.
(the torrent was older than today)
PS: I use sparse files.

[alexw]

Just did a test and it is caused by using sparse files. I just switched to pre-allocation and downloaded a torrent, and the "modified" date of the files is correctly set to when the torrent finished downloading, while the "created" date was left to when the file was created (when torrent was added). I guess this should be reported to libtorrent then so they can fix it for sparse files as well.

I'm using Win 8.1 Pro x64. Partition is NTFS 3.1. qBittorrent 3.1.11

EDIT: I just saw your reply. Hmm, could be Win8 vs WinXP. I'm also using a HDD.

EDIT2: Even though the "modified" date was changed, it was changed only once when download finished. It was not updating while it was downloading like in your case. This may be indeed a difference between Win8 and WinXP. Are you also using NTFS 3.1 in WinXP? Even so, Win 8 does have a different ntfs.sys which does a few things differently than XP (handles symlinks, different update periods for "last accessed", etc). The best fix seems to be for libtorrent to just force a date change after download is done rather than rely on the OS.

[drumtail]

I created an account so I could post this.

@alexw, do you by any chance use SSD caching on that HDD (like Intel Rapid Response)? I've experienced the same behavior for a while while using Intel Rapid Response, but now it's back to normal. I can't remember what I changed though, but it was probably one of the following: updating the Intel RAID drivers, updating the BIOS (it holds the intel RAID firmware), deactivated and then reactivated the HDD acceleration for the HDD. I assume @sledgehammer was not using any SSD caching for his HDD when he did his test?

@ciaobaby, as entertaining as your posts were, you need a really serious attitude adjustment, even more so given you are a moderator. Your +/- ratio should worry you and the administrator. On top of that, you showed how little you understand about an OS (and bittorrent clients). The public burn you received in this thread would make any decent person cringe.