Discussion:
[libtorrent] rename file?
Alexander Dyagilev
2017-05-05 06:54:07 UTC
Permalink
Hello,

Unfortunately, rename_file renames files on disk.

What if I want to just download to another name?

Example: I already have a file called setup.exe on my disk. I've got a
new torrent with different file called setup.exe also. I want it to be
downloaded in the same location but with a different name. E.g.
setup(1).exe.

Now, if I call rename_file it renames the file on disk and overwrites it.
Arvid Norberg
2017-05-06 10:11:27 UTC
Permalink
On Fri, May 5, 2017 at 2:54 AM, Alexander Dyagilev <***@gmail.com>
wrote:

> Hello,
>
> Unfortunately, rename_file renames files on disk.
>
> What if I want to just download to another name?
>

You can rename the file in the torrent_info object (i.e. the .torrent
file). I assume what you're doing now is to call rename_file on the
torrent_handle (which means you've already started the torrent, and
attached it to a download directory).

If you rename the file before you add the torrent, it will be as if it had
a different name all long.

You can use either rename_file() or remap_files() (the latter for more
advanced uses).

http://libtorrent.org/reference-Core.html#remap_files()

--
Arvid Norberg
Alexander Dyagilev
2017-05-09 13:25:02 UTC
Permalink
Thank you for the response.

What if I add a magnet? Once the metadata is received, is there a way to
do rename w/o renaming the existing file?


On 5/6/2017 1:11 PM, Arvid Norberg wrote:
> On Fri, May 5, 2017 at 2:54 AM, Alexander Dyagilev <***@gmail.com>
> wrote:
>
>> Hello,
>>
>> Unfortunately, rename_file renames files on disk.
>>
>> What if I want to just download to another name?
>>
> You can rename the file in the torrent_info object (i.e. the .torrent
> file). I assume what you're doing now is to call rename_file on the
> torrent_handle (which means you've already started the torrent, and
> attached it to a download directory).
>
> If you rename the file before you add the torrent, it will be as if it had
> a different name all long.
>
> You can use either rename_file() or remap_files() (the latter for more
> advanced uses).
>
> http://libtorrent.org/reference-Core.html#remap_files()
>
Arvid Norberg
2017-05-09 17:15:12 UTC
Permalink
On Tue, May 9, 2017 at 9:25 AM, Alexander Dyagilev <***@gmail.com>
wrote:

> Thank you for the response.
>
> What if I add a magnet? Once the metadata is received, is there a way to
> do rename w/o renaming the existing file?


Yes. By saving off the .torrent file, removing the torrent from the session
and re-add it again with modified torrent_info.

--
Arvid Norberg
Arvid Norberg
2017-05-25 11:26:16 UTC
Permalink
On Thu, May 25, 2017 at 4:37 AM, Alexander Dyagilev <***@gmail.com>
wrote:

> Hello,
>
> Race condition bug then?
>
> I process meta data received alert in another thread.
>
> LT continues download while I process it.
>
> Even if I pause torrent immediately after receiving this alert (and before
> starting to process it), isn't there a chance that LT will have time to
> create some files?
>

That's what flag_stop_when_ready is for, see
http://www.libtorrent.org/reference-Core.html#add_torrent_params

Now that I look at it, it looks like downloading-metadata may count as
"downloading". I wonder if this was a mistake. This flag is useful for just
*checking* a torrent but not start downloading it, but it seems like it
would be really useful to for this feature to also trigger on the
downloading-metadata -> downloading edge.

--
Arvid Norberg
Alexander Dyagilev
2017-06-02 09:39:28 UTC
Permalink
Does not work for me.

I don't receive libtorrent::metadata_received_alert at all in case I
enable this flag.


On 5/25/2017 2:26 PM, Arvid Norberg wrote:
> On Thu, May 25, 2017 at 4:37 AM, Alexander Dyagilev
> <***@gmail.com <mailto:***@gmail.com>> wrote:
>
> Hello,
>
> Race condition bug then?
>
> I process meta data received alert in another thread.
>
> LT continues download while I process it.
>
> Even if I pause torrent immediately after receiving this alert
> (and before starting to process it), isn't there a chance that LT
> will have time to create some files?
>
>
> That's what flag_stop_when_ready is for, see
> http://www.libtorrent.org/reference-Core.html#add_torrent_params
>
> Now that I look at it, it looks like downloading-metadata may count as
> "downloading". I wonder if this was a mistake. This flag is useful for
> just *checking* a torrent but not start downloading it, but it seems
> like it would be really useful to for this feature to also trigger on
> the downloading-metadata -> downloading edge.
>
> --
> Arvid Norberg
Alexander Dyagilev
2017-06-02 09:49:08 UTC
Permalink
However, I've decided to use another workaround.

I create magnet with a temporary lonely save_path.

Once I receive alert, I rename files using torrent_handle and then move
storage to the target path.


On 6/2/2017 12:39 PM, Alexander Dyagilev wrote:
>
> Does not work for me.
>
> I don't receive libtorrent::metadata_received_alert at all in case I
> enable this flag.
>
>
> On 5/25/2017 2:26 PM, Arvid Norberg wrote:
>> On Thu, May 25, 2017 at 4:37 AM, Alexander Dyagilev
>> <***@gmail.com <mailto:***@gmail.com>> wrote:
>>
>> Hello,
>>
>> Race condition bug then?
>>
>> I process meta data received alert in another thread.
>>
>> LT continues download while I process it.
>>
>> Even if I pause torrent immediately after receiving this alert
>> (and before starting to process it), isn't there a chance that LT
>> will have time to create some files?
>>
>>
>> That's what flag_stop_when_ready is for, see
>> http://www.libtorrent.org/reference-Core.html#add_torrent_params
>>
>> Now that I look at it, it looks like downloading-metadata may count
>> as "downloading". I wonder if this was a mistake. This flag is useful
>> for just *checking* a torrent but not start downloading it, but it
>> seems like it would be really useful to for this feature to also
>> trigger on the downloading-metadata -> downloading edge.
>>
>> --
>> Arvid Norberg
>
Alexander Dyagilev
2017-06-02 10:40:04 UTC
Permalink
I've got another problem... :(

After I move storage to the target path and got storage_moved_alert, I
call torrent_handle::force_recheck.

But it has no effect.... LT just overwrites existing file starting from
0% without rechecking it....

(yes, sometime I need to rename to a different name, e.g. setup(1).exe,
and sometimes I decide to just continue to download existing file).


On 6/2/2017 12:49 PM, Alexander Dyagilev wrote:
>
> However, I've decided to use another workaround.
>
> I create magnet with a temporary lonely save_path.
>
> Once I receive alert, I rename files using torrent_handle and then
> move storage to the target path.
>
>
> On 6/2/2017 12:39 PM, Alexander Dyagilev wrote:
>>
>> Does not work for me.
>>
>> I don't receive libtorrent::metadata_received_alert at all in case I
>> enable this flag.
>>
>>
>> On 5/25/2017 2:26 PM, Arvid Norberg wrote:
>>> On Thu, May 25, 2017 at 4:37 AM, Alexander Dyagilev
>>> <***@gmail.com <mailto:***@gmail.com>> wrote:
>>>
>>> Hello,
>>>
>>> Race condition bug then?
>>>
>>> I process meta data received alert in another thread.
>>>
>>> LT continues download while I process it.
>>>
>>> Even if I pause torrent immediately after receiving this alert
>>> (and before starting to process it), isn't there a chance that
>>> LT will have time to create some files?
>>>
>>>
>>> That's what flag_stop_when_ready is for, see
>>> http://www.libtorrent.org/reference-Core.html#add_torrent_params
>>>
>>> Now that I look at it, it looks like downloading-metadata may count
>>> as "downloading". I wonder if this was a mistake. This flag is
>>> useful for just *checking* a torrent but not start downloading it,
>>> but it seems like it would be really useful to for this feature to
>>> also trigger on the downloading-metadata -> downloading edge.
>>>
>>> --
>>> Arvid Norberg
>>
>
Alexander Dyagilev
2017-06-02 12:32:23 UTC
Permalink
Here is the bug report:

https://github.com/arvidn/libtorrent/issues/2054


On 6/2/2017 1:40 PM, Alexander Dyagilev wrote:
>
> I've got another problem... :(
>
> After I move storage to the target path and got storage_moved_alert, I
> call torrent_handle::force_recheck.
>
> But it has no effect.... LT just overwrites existing file starting
> from 0% without rechecking it....
>
> (yes, sometime I need to rename to a different name, e.g.
> setup(1).exe, and sometimes I decide to just continue to download
> existing file).
>
>
> On 6/2/2017 12:49 PM, Alexander Dyagilev wrote:
>>
>> However, I've decided to use another workaround.
>>
>> I create magnet with a temporary lonely save_path.
>>
>> Once I receive alert, I rename files using torrent_handle and then
>> move storage to the target path.
>>
>>
>> On 6/2/2017 12:39 PM, Alexander Dyagilev wrote:
>>>
>>> Does not work for me.
>>>
>>> I don't receive libtorrent::metadata_received_alert at all in case I
>>> enable this flag.
>>>
>>>
>>> On 5/25/2017 2:26 PM, Arvid Norberg wrote:
>>>> On Thu, May 25, 2017 at 4:37 AM, Alexander Dyagilev
>>>> <***@gmail.com <mailto:***@gmail.com>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Race condition bug then?
>>>>
>>>> I process meta data received alert in another thread.
>>>>
>>>> LT continues download while I process it.
>>>>
>>>> Even if I pause torrent immediately after receiving this alert
>>>> (and before starting to process it), isn't there a chance that
>>>> LT will have time to create some files?
>>>>
>>>>
>>>> That's what flag_stop_when_ready is for, see
>>>> http://www.libtorrent.org/reference-Core.html#add_torrent_params
>>>>
>>>> Now that I look at it, it looks like downloading-metadata may count
>>>> as "downloading". I wonder if this was a mistake. This flag is
>>>> useful for just *checking* a torrent but not start downloading it,
>>>> but it seems like it would be really useful to for this feature to
>>>> also trigger on the downloading-metadata -> downloading edge.
>>>>
>>>> --
>>>> Arvid Norberg
>>>
>>
>
Alexander Dyagilev
2017-06-08 20:12:13 UTC
Permalink
Hello,

Meow....


On 6/2/2017 3:32 PM, Alexander Dyagilev wrote:
>
> Here is the bug report:
>
> https://github.com/arvidn/libtorrent/issues/2054
>
>
> On 6/2/2017 1:40 PM, Alexander Dyagilev wrote:
>>
>> I've got another problem... :(
>>
>> After I move storage to the target path and got storage_moved_alert,
>> I call torrent_handle::force_recheck.
>>
>> But it has no effect.... LT just overwrites existing file starting
>> from 0% without rechecking it....
>>
>> (yes, sometime I need to rename to a different name, e.g.
>> setup(1).exe, and sometimes I decide to just continue to download
>> existing file).
>>
>>
>> On 6/2/2017 12:49 PM, Alexander Dyagilev wrote:
>>>
>>> However, I've decided to use another workaround.
>>>
>>> I create magnet with a temporary lonely save_path.
>>>
>>> Once I receive alert, I rename files using torrent_handle and then
>>> move storage to the target path.
>>>
>>>
>>> On 6/2/2017 12:39 PM, Alexander Dyagilev wrote:
>>>>
>>>> Does not work for me.
>>>>
>>>> I don't receive libtorrent::metadata_received_alert at all in case
>>>> I enable this flag.
>>>>
>>>>
>>>> On 5/25/2017 2:26 PM, Arvid Norberg wrote:
>>>>> On Thu, May 25, 2017 at 4:37 AM, Alexander Dyagilev
>>>>> <***@gmail.com <mailto:***@gmail.com>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Race condition bug then?
>>>>>
>>>>> I process meta data received alert in another thread.
>>>>>
>>>>> LT continues download while I process it.
>>>>>
>>>>> Even if I pause torrent immediately after receiving this alert
>>>>> (and before starting to process it), isn't there a chance that
>>>>> LT will have time to create some files?
>>>>>
>>>>>
>>>>> That's what flag_stop_when_ready is for, see
>>>>> http://www.libtorrent.org/reference-Core.html#add_torrent_params
>>>>>
>>>>> Now that I look at it, it looks like downloading-metadata may
>>>>> count as "downloading". I wonder if this was a mistake. This flag
>>>>> is useful for just *checking* a torrent but not start downloading
>>>>> it, but it seems like it would be really useful to for this
>>>>> feature to also trigger on the downloading-metadata -> downloading
>>>>> edge.
>>>>>
>>>>> --
>>>>> Arvid Norberg
>>>>
>>>
>>
>
M***@massaroddel.de
2017-05-26 06:01:14 UTC
Permalink
> Hello,
>
> Race condition bug then?
>
> I process meta data received alert in another thread.
>
> LT continues download while I process it.
>
> Even if I pause torrent immediately after receiving this alert (and
> before starting to process it), isn't there a chance that LT will have
> time to create some files?
>
> So, I'll see some "setup.exe" file on disk and I rename it to
> setup(1).exe and re-add torrent. Thus there will be 2 files: setup.exe
> with a trash and actual setup(1).exe. While it was supposed to be there
> setup.exe only cause it did not exist initially.
>
>
> On 5/9/2017 8:15 PM, Arvid Norberg wrote:
> > On Tue, May 9, 2017 at 9:25 AM, Alexander Dyagilev
> > <***@gmail.com <mailto:***@gmail.com>> wrote:
> >
> > Thank you for the response.
> >
> > What if I add a magnet? Once the metadata is received, is there a
> > way to do rename w/o renaming the existing file?
> >
> >
> > Yes. By saving off the .torrent file, removing the torrent from the
> > session and re-add it again with modified torrent_info.
> >
> > --
> > Arvid Norberg

You can either provide a large file priorities vector (priority 0) in add_torrent_params
or use this patch and provide a single file priority in add_torrent_params.

in torrent::init()
..
// use the first file priority as default
if (!m_file_priority.empty() && (int(m_file_priority.size()) < m_torrent_file->num_files()))
{
m_file_priority.resize(m_torrent_file->num_files(), m_file_priority[file_index_t(0)]);
}
..

MassaRoddel
Arvid Norberg
2017-05-27 03:12:13 UTC
Permalink
On Fri, May 26, 2017 at 2:01 AM, <***@massaroddel.de> wrote:
>
> You can either provide a large file priorities vector (priority 0) in
> add_torrent_params
> or use this patch and provide a single file priority in add_torrent_params.
>
> in torrent::init()
> ..
> // use the first file priority as default
> if (!m_file_priority.empty() && (int(m_file_priority.size()) <
> m_torrent_file->num_files()))
> {
> m_file_priority.resize(m_torrent_file->num_files(),
> m_file_priority[file_index_t(0)]);
> }
>

Thanks for reminding me of the file_priorities trick. I have a patch to
extend the documentation.

https://github.com/arvidn/libtorrent/pull/2032

--
Arvid Norberg
Loading...