descript.ion file does not reflect autorenamed files

[RayMark]

This is a new problem, I noticed it in 6.20, it is also still present in 6.30 beta 2.
Previously everything was working fine, not sure until which version

If there are files with the same name, they are autorenamed:

file1.rar
file1-(0001).rar
file1-(0002).rar

In discript.ion file, now each file is present incorrectly as the same:
"file1.rar".
"file1.rar".
"file1.rar".

It should be (and previously was !!!):
"file1.rar"
"file1-(0001).rar"
"file1-(0002).rar"

This new change makes description files pretty much useless.
Previously, it was possible to look/search inside the descript.ion file and know which exactly file you needed.
Now it is no longer possible.
Furthermore, if a file such as file1-(0002).rar is copied or moved to a different folder (with FAR, for example), the descrip.tion files in the source and target folders are not updated, so in both folders they become out of date.
In the source folder, some description lines remain in descript.ion file without the corresponding actual files present, in the target folder, descript.ion file is not created or, if already present, the corresponding new line is not added.

I am explaining all this in detail because I have an uneasy feeling that it was done deliberately as an "improvement".
If so, no, it is NOT an improvement!!!
It is a very nasty bug, it makes working with downloaded files so much more difficult and many times more time-consuming.

Please restore the previous behavior, or add to preferences a choice.

[Moondawgie]

And it's a shame that descript.ion files aren't created for inflated/unrared files.

<Grin, duck, and run>

[RayMark]

Come on, this issue is still not fixed in 6.30 beta 4 !!!

Quade, have you even seen this my post about this problem?

It is a pretty serious issue - I rely on descript.ion files to determine which renamed file is which.
Now, that the original names are used inside the descript.ion files instead of the renamed ones, it is no longer possible.
So what if I get all the files thanks to renaming if I cannot tell which is which? descript.ion file now became useless in that regard.
And furthermore, descriptions now cannot be and are not handled correctly when moving/copying files to other folders.

BTW, it is not working correctly (as previously) even though I am in the 5.59 mode (autopar disabled).

[Quade]

The problem is that it's not the new files that are being renamed but, the files on disk are being renamed to make room for the new files. So, a complete re-write of the descript.ion file with each duplicate filename would be required. Autopar needs this and I'm not going to break Autopar for descript.ion files.

[RayMark]

Autopar is switched off !!!
It does not exist to me.

Do whatever you want when autopar is on. But please handle descriptions and renaming as in older versions of Newsbin when autopar is off.
The code already was written, no need to do it again.
When autopar is off, no fancy stuff should be done, no file types recognized, just straightforward regular download.

descript.ion file is the easiest way to find the needed file among multiple renamed files.
Otherwise the content of each file has to be examined to find the needed one, and sometimes there are hundreds of such renamed files.
Furthermore, for some file types (and/or depending of how things are named inside) even examining content does not help.



A SUGGESTION - even when AutoPAR is on - better than nothing:

Perhaps you could still use renamed file names inside the descript.ion file:

When you are renaming the previously downloaded to file-(0004), you put that number to the name of the new file.
That way, we would have renamed names, cyclicly shifted by 1 - still pretty easy to find the needed file when you are aware of the shift.

ALTERNATIVE:
- to re-write the whole file.
Consider this: in most cases, if there are not many renamings, and/or if not many items in descript.ion - it will not be an issue at all.
But when people have many items and multiple renamings - then they know what to expect.
After all, when a file is moved by a file manager which supports descript.ion files, descript.ion is also re-written, sometimes it takes quite long.
So the same could be done by Newsbin.

[Quade]

Autopar is switched off !!!
It does not exist to me.

All that means is that Newsbin doesn't manage the par files. It doesn't change how it downloads in order to support autopar.

I'll consider it. If it's not particularly error prone to switch rename modes, I might do it.

[RayMark]

I wonder when exactly renamed names disappeared from descript.ion files.
Which was the last version of Newsbin still to support them?
Switching back from version 6 headers would be difficult.

[ppan]

The problem is that it's not the new files that are being renamed but, the files on disk are being renamed to make room for the new files. So, a complete re-write of the descript.ion file with each duplicate filename would be required. Autopar needs this and I'm not going to break Autopar for descript.ion files.

I just upgraded from v5.59 to v6.21, and I was not aware that the descriptions may now not be correct (after file renaming) !?
I also rely heavily on the descriptions.

I thought that the new files were being renamed (e.g. copy (1) of somefile.jpg)? I believe that is how it worked in v5.59?
Why was this changed? Can't Autopar work with the old renaming method (renaming the new files), like it did in v5.59?

Please try to correct this.
Thxs!

[Quade]

Image files rename the old way. Files that belong to RAR/PAR sets rename the new way. I don't see that changing.

[RayMark]

I was not aware that renamed image files are reflected correctly in descript.ion. I just assumed all the files were badly treated.
Now I tested with beta 2 - yes, the image files are correct!

So the problem is with par/rar files only?

If AutoPAR is disabled, then rar/par files are just ordinary regular files without any special meaning and they should be renamed the old way.
And it is already implemented - nothing new to implement. Just disable recognizing and handling rar/par files as special files.
I realize it is only a partial fix - only when AutoPAR is disabled. But I have AutoPAR always disabled, so this partial solution is enough for me.
When AutoPAR / auto unrar is enabled things are handled automatically and renamed files in descript.ion are no longer an issue - if the source files are no longer needed and deleted.
So this solution (which is already implemented!) for the case when AutoPAR is disabled is all that is needed, really.

We had this discussion about it in other threads.
I consider it a bug if rar/par files are still given any special treatment when AutoPAR is disabled. End of story. Newsbin should not be too smart against the user's will.
Especially if being too smart results in something else than the user expects and wants.

An exception might be spam checking inside rar files if they contain password protected inner archives or contain exe inside, etc.
But it is possible to enable /disable such checks in options already.
So this limited special treatment of rar files is controlled by other options than AutoPAR enable/disable and does not contradict the general rule.