Feature request: Don't preserve File Creation Date

[elmargol]

I use rsync to sync all my downloads to a remote host.

The problem is some rar archives preserve the modification date of a file.
I have solved this problem using this patch. Can we have something similar included?

Code: Select all

--- /usr/share/sabnzbdplus/sabnzbd/postproc.py_orig     2010-11-15 21:54:48.000000000 +0100
+++ /usr/share/sabnzbdplus/sabnzbd/postproc.py  2011-02-02 14:51:54.000000000 +0100
@@ -318,6 +318,7 @@
                     else:
                         nzo.set_unpack_info('Unpack',T('msg-noPostProc'))

+
                 ## Move any (left-over) files to destination
                 nzo.set_status('Moving')
                 nzo.set_action_line(T('msg-moving'), '...')
@@ -337,6 +338,12 @@
                     logging.info("Traceback: ", exc_info = True)


+               ##Touch all files
+                for root, dirs, files in os.walk(tmp_workdir_complete):
+                    for _file in files:
+                       logging.info("Touching %s", os.path.join(root, _file))
+                       os.utime(os.path.join(root, _file), None)
+
                 ## Set permissions right
                 if not sabnzbd.WIN32:
                     perm_script(tmp_workdir_complete, cfg.UMASK.get())

[shypike]

You are assuming that everybody wants this.
The alternative is to run a user script that does this.

[elmargol]

There is no way to do this using a userscript if it is a TV show.

Since sabnzbd only provides the path and not the files.

[shypike]

Get gnu-touch and gnu-find and run this:

\path\find %1 -type d -exec \path\touch {} ;
\path\find %1 -type f -exec \path\touch {} ;

http://gnuwin32.sourceforge.net/packages.html

[elmargol]

This was the first thing i tried.

This works for normal downloads.

It is not going to work if you enable "TV Sorting"

example:

You download "Name of the show.S01.E01-foobar exists.mkv" it gets moved to
-> Name of the show/series 1/Name of the show.S01.E01-foobar exists.mkv

%1 = $PATH_TO_COMPLETE_FOLDER/Name of the show/series 1/

1 file gets touched.

some time later you download
"Name of the show.S01.E01-foobar does not exists.mkv"

%1 = $PATH_TO_COMPLETE_FOLDER/Name of the show/series 1/

2 files get touched

Name of the show/series 1/Name of the show.S01.E01-foobar exists.mkv
Name of the show/series 1/Name of the show.S01.E01-foobar does not exists.mkv

[shypike]

Yeah, the TV Sort is a bit of nuisance.
It might mean that access rights adjustments (for Linux and OSX) are affected too.
I'll look into this.

[diamaunt]

something like this issue causes me problems, on the unix side, some of the rar files that come in have an invalid/inaccurate date in them, and upon unpacking, the resultant file has a unix date of 0, ie, the epoch... for me after time zone correction, Dec 31 1969.

for some reason, this cause the linux mythtv front ends I've got to not recognize the file across the nfs mounts.

it'd be *really* nice to have an option (in the switches?)  in sabnzbd to say "timestamp incoming files with current time"...

or maybe, just look at the file date of the new file, and if predates video files *Grin* have sab say "tsk tsk tsk, no, this'll never do, lemme fix that *touch*" *grins*

Thanks for the consideration.

[shypike]

That feature already exists as a "hidden" option.
http://wiki.sabnzbd.org/configure-special item ignore_unrar_dates
Only for 0.6.0 RC2

[diamaunt]

WOOT!  

thanks...

of course, how're we 'sposed to know 'bout it, if you're being sneaky and hiding it from us?

oh, wait, I just noticed it's in the "not out yet" version   which I can't seem to find  a link to.

[shypike]

oh, wait, I just noticed it's in the "not out yet" version   which I can't seem to find  a link to.

Just click on the message News: 0.6.0RC2 is out! at the top left corner of this page.

[diamaunt]

thank you...

for being patient, and for the good work...

I really looked everywhere I could think of, (except, obviously, up there) and did find rc1, but didn't see anything on rc2.

I'll give it a shot and report back if I can manage to break anything *grin*

[shypike]

How about this?
http://sourceforge.net/projects/sabnzbd ... -0.6.0RC2/

[diamaunt]

Sorry, I wasn't clear, after your first post about the feature in rc2, I looked everywhere I could think of, and could only find info up to RC1, even on launchpad, and couldn't find any reference to anything past rc1.

then you mentioned that it was up there on the top left corner of the page, and I felt silly for having missed that.  (though, it is a bit subtle *grins).

I went to that link, and downloaded the source, dropped it onto my system, and am using it, and will report back if I find anything that's a problem.

I know it's nitpicking, and this may not be the right place, but, the changes to the deleting things from the history are a mild annoyance to me, I liked being able to turn off the confirmation, and just go down the row clicking the x's, to delete things from the queue.  now each click I have to select whether to remove nzb or remove nzb and delete files (which is greyed out)

I haven't been able to figure out why I'd want to delete files, unless that's all the file bits before being assembled and decoded into the final result, but those are all deleted automatically with my settings.

In short, I miss the "don't confirm history deletions" option, and haven't seen where I can set something like that again.

the hidden option to ignore the internal timestamp on rar files seems to be working nicely.... thank you very much for that!

[shypike]

The question is mainly for failed entries.
We've been struggling a bit with the UI to avoid too many popup's.
Please read this to appreciate the full package before starting to nitpick
http://wiki.sabnzbd.org/introducing-0-6-0

[diamaunt]

what? I've got all my nitpicks, er, user feedbacks, all lined up! (I'm KIDDING!, don't hurt me!)

I see what you're doing, and I don't know if it'd be too much trouble to code back in a 'don't ask on history  deletions' when there's no files to be deleted (currently greyed out).

if it stays like it is, I'll deal, probably just doing a clear of the whole history.

It was a minor nitpick, amid plenty of pleasures at the other new features.

Keep up the good work, it's appreciated.