SABnzbd Forums

Version: 0.5.0
OS:Windows XP SP3
Install-type: Windows Installer
Skin (if applicable): smpl-black
Firewall Software: None
Are you using IPV6? no
Is the issue reproducible? (yes/no) no.

Have found the odd file when unpacked (automatically) has a file date of 01/01/2098.  Being in New Zealand my date format regularly is dd/mm/yyyy.

Not sure what is setting the date, am assuming it's in the unpack/unrar process.  Not sure if there is anything I can provide to help.  Just had a quick look through the log and couldn't see anything relating to dates at the end of the download of this particular file

SABnzbd doesn't do anything with file dates, it lets the OS do that.
Unrar does it's own thing.
If the funny files came out of a RAR file, I suspect that the poster did something wrong.

Yes that is the answer that I expected.  Are there any switches thrown to unrar that tell it to try and preserve the dates?  or any switch that could be thrown to make it not try to preserve a date if that's the default behaviour?

I ran into the issue as well and want to know the same thing. The problem in my case is that the target machine (Synology NAS EXT4) doesn't allow this date (2098.. etc) and saves the file in a way which appears to have NO modified date. The 2038 problem? That means that most applications cant open the file.

If I just unrar it manually to a WINDOWS volume using powerarchiver or whatever it gets the future date written. And I can later manually set the last "modified date" to the whatever which is not possible if sab / unrar has done the unpacking.

Is the preservation of the modified date field a sab / unrar feature or as you suggest an OS issue? Can it be forced?

You can tell unrar to suppress date handling with the -tsm- flag.
Maybe we can make this a "hidden" option.

If you're brave you can hack the file sabnzbd/newsunpack.py yourself
Change line 456 to read: