Renaming of broken files

Get help, report and discuss bugs.
khermansen

Renaming of broken files

Post by khermansen » 18 Mar 2005, 05:56

Hi,

I think that nzbget is pretty cool, but the file renaming on broken files is not a useful feature!!! I think it would be better if the files stayed broken, but named the same on disk. The reasoning is that when you execute the par2repair command, it will never find that file unless you rename it back. It would just be better to keep it broken on disk with the original filename from the newsgroup.

The offending code is in FileDownloader.cpp here:

<snip>
if (complete)
{
m_pJob->setStatus(JOBSTATUS_FINISHED);
// info("Decoded %s", ofn);
}
else
{
char brokenfn[1024];
snprintf(brokenfn, 1024, "%s_broken", ofn);
rename(ofn, brokenfn);
m_pJob->setStatus(JOBSTATUS_FAILED);
warn("%s is incomplete!", ofn);
}
</snip>

I think many would agree that this code should be changed when thinking about par2 recovery. Anyone disagree? Should we vote?

This is basically a small fix, so I don't think it is necessary for me to make a patch, but please let me know if I should. Who has the ability to modify the CVS source? I'm actually pretty new to the Linux scene and open source software in general so any help is appreciated, thanks!

Kristian Hermansen

pmorch

RE: Renaming of broken files

Post by pmorch » 18 Mar 2005, 06:34

Perhaps this should be a configuration option.
The advantage with the current "%s_broken" naming convention is that it is obvious to the eye that a download has failed.

A quick
$ rename 's/_broken//' *
removes all the "_broken" strings from the filenames, so this is no problem for me.

But I suggest that if this is changed, lets make it into a configuration option in the ~/.nzbget/nzbget.cfg file.

khermansen

RE: Renaming of broken files

Post by khermansen » 18 Mar 2005, 08:16

Ok, that sounds fine. How should we go about it? Should I make the changes to the code and post a patch or what? I'm thinking that we will just read in the option from the config into some var and do an if(BROKEN_RENAME) to execute that rename code section. Sound okay?

Kristian Hermansen

wfhiker

RE: Renaming of broken files

Post by wfhiker » 18 Mar 2005, 08:26

I use par2cmdline like this:
par2repair file.par2 *broken

Works for me with par2cmdline 0.4.

placebodk

RE: Renaming of broken files

Post by placebodk » 19 Mar 2005, 17:01

Kristian, currently I am the only one who is blessed with the ability to commit to CVS.

As it is right now I am not the best person to decide whether or not the changes to renaming the broken files that you describe is for the better or the worse - I must shamefully admit that I use Window$ to run par2 and thus have no real experiences with par2repair. Have you tried if wfhiker's approach works for you as well?

But as pmorch mentions it wouldnt hurt to have it as an option - it might even be great. If you make a patch I would happily commit it to the repository - note however, that the current code found in CVS is a greatly mutated version of the 0.2.0 (ie. a patch made for either will very likely not fit the other).

As mentioned in another thread on the forums I do have plans on looking into running par2repair automaticly, actually it is one of the next things I have planned to do, however my current efforts are focused towards squashing the bugs related to downloads pausing and download-threads running wild - It's taking a bit longer than anticipated because the code doesnt fail at once but need to be running for a while before reproduction occurs (ie. a pain to debug).

What this means is that the code in CVS (and hence a path target for it) will not be released before enough "pesticide" has been applied and the mentioned bugs have been squashed.

/placebodk

khermansen

RE: Renaming of broken files

Post by khermansen » 20 Mar 2005, 04:57

Yes, I think that making it a option via the nzbget.cfg file is the best way to go. I will keep renaming of broken files on by default for those who have not specified it in their config, and I'll just update it on my own config file so that it works for me and others can use the option too. This sounds like the best way to go. I'll try to get the patch out soon for the latest in CVS.

I'm actually also fairly new to the whole Linux scene and CVS/OSS projects. If there a guide someone would like to recommend for creating patches and submitting them? Is there some sort of preferred way of doing this like a coding/style guide for acceptable code and acceptable pacthes? Thanks in advance...any help is appreciated ;-)

Kristian Hermansen

pmorch

RE: Renaming of broken files

Post by pmorch » 20 Mar 2005, 09:19

Creating a patch:

$ cp -a nzbget nzbget.orig
$ cd nzbget
$ vi * # edit away... :-D
$ cd ..
$ diff -Naur nzbget.orig nzbget > nzbget.patch

`man diff` to see what it does. The -u option is the most important.

placebodk

RE: Renaming of broken files

Post by placebodk » 20 Mar 2005, 10:03

>$ vi * # edit away... :-D

[Insert religious banter about emacs opposed to vi]

Actually I can highly recommend kdevelop to anyone who isn't 100% unix hardcore and actually wan't something mildly resembling an API. At work we use Visual Studio and kdevelop, in my opinion, has around 80% of the same functionalty.

Just my $0.02

/placebodk

khermansen

RE: Renaming of broken files

Post by khermansen » 27 Mar 2005, 11:23

I have currently modified the source to implement this renamebroken feature, but I have run into a few bugs. First off, I have trouble understanding what this line specifically does in Options.cpp:

static char short_options[] = "a::c:d:D::hm:t:l:r:b:snv";

I know it is the short options for the command line args, and I added the "b" option -- but I think this one line is screwing my patch. I don't understand the ":", why there are two in some places and one in another and, none at the end!??! What does this line really do?

Also, I seem to have a problem that sometimes CL args or config file args will override each other. I would think that CL args take precedence over config file args which take precedence over DEFAULT values. It may just be that I have minged the code in a few places that is causing this error -- but any help from you guys is greatly appreciated. As I said before, I am quite new to the OSS scene...thanks :-)

Kristian Hermansen

pmorch

RE: Renaming of broken files

Post by pmorch » 27 Mar 2005, 19:35

From `man getopt_long` (or e.g. http://www.rt.com/man/getopt.3.html)

optstring is a string containing the legitimate option characters. If
such a character is followed by a colon, the option requires an argu-
ment, so getopt places a pointer to the following text in the same
argv-element, or the text of the following argv-element, in optarg.
Two colons mean an option takes an optional arg; if there is text in
the current argv-element, it is returned in optarg, otherwise optarg is
set to zero. This is a GNU extension. If optstring contains W fol-
lowed by a semicolon, then -W foo is treated as the long option --foo.
(The -W option is reserved by POSIX.2 for implementation extensions.)
This behaviour is a GNU extension, not available with libraries before
GNU libc 2.

I think this is what you're asking about, right?

Peter

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 3 guests