EPERM: operation not permitted, rename ...

[B K]

Hi,

Being a loong time paying user of VDH I have run into this EPERM rename problem many times. As I understand it, the developer cannot recreate the problem. Unfortunately, so can MANY of us users.

It appears to be unpredictable. Suggestions and possible fixes run in all directions, including that there are something wrong with the disks, the file (which is only used by VDH, when you download for the first time) is in use, etc.

So, my understanding is that no one really has any idea of what it is.

Numerous users report that changing disk etc. cannot be the problem. Why would VDH work on one video but not on another, when the download directory is unchanged for years.

It must be a specific coding bug, since this type of problem does not occur in other programs, but must then be a subtle one, since it cannot be recreated by the developer.

So, I am wondering about what the difference is btw the developers system and the annoyed user's.

One thing can be is VDH is using more than one thread. This is sometimes difficult to know, if you are not very familiar with the structure of the underlying APIs. On a loaded machine, one thread may accidentally lock out another, due to slowness in the OS.

It seems to appear more often in larger downloads than in shorter ones. So, one place to look is if the close operation of one file has really terminated or the corresponding API just returns after having started the thread, instead of after the closure of the file and release of the lock. There are many other setups also.

So, my suggestion is that the part of the code where the rename operation is performed is rewritten slightly - and e.g. put in a 1 sec delay somewhere, to see if that makes a difference.

Furthermore, I suggest that the developer, after not having been able to solve this problem for years, try to use one of us users, in trying to debug the problem, and perhaps install a test version, to see if that cures the problem. Mind you though, this can be triggy, since if it has to do with a race condition, any tweaking with the system may seem to alleviate the problem, whereas it may pop up at other users.

The users I know having switched from VDH all did it because of this problem. Sp, it is worth looking more into, that just stating that it cannot be recreated. The earth is round - even though you may not be able to see it from where you stand :-)

[jcv...@gmail.com]

hi,

"since this type of problem does not occur in other programs", not sure about this : https://www.google.com/search?q=EPERM+error

A lot of things could be try from this search. If you can reproduce the problem on your config, it would be great if you could test some of the proposed solutions.

jerome

[B K]

Thanks Jerome for your answer. I have never thought about searching in this manner. It seems most of the other EPERM issues have to do with using npm or node. I am not familiar with neither npm,, which seems to be a package manager for Javascript nor node, which seems to used for writing server side javascripts. I do not know in what language VDH is written nor if npm or node somehow has anything to do with this problem. But if the EPERM error occurs within a Javascript module, it could be. However, VDH does not use npm, node nor Javascript or...?

So, if VDH is written e.g. in C++ or C and do not use any Javascript, it is difficult to see how this race condition causing hte problem can occur. But I had one application (not used since 2015) which included node, on my machine, which I have deleted. npm I do not know that I have. the fixes I find all relate to clearing the cache of node or npm, which is not possible when you do not have on your machine.

And deleting node unfortunately had no effect on the URL https://www.somabreath.com/masterclass-live-fb/ :-(

I will try to see if there are other clues in the URLs found by the google search on EPERM. so far - no luck.

[Wild Willy]

I visited your somabreath page to see what I could get. I'm running on Windows 7 64-bit,
Firefox 93.0 64-bit, licensed VDH 7.6.3a1 beta, CoApp 1.6.3. I did what you can see in
the attached images. In short, it simply worked for me. I have 6 physical hard drives
with a variety of partitions & I regularly download things onto all of them. The
directory here is in a partition that is on my disk 0 which also happens to contain my
boot partition (C:). It is my understanding that this EPERM error has something to do
with permissions. If you aren't trying to save to the boot partition, it is unlikely
that you don't have read & write access to the directory. In the Windows boot partition,
it's possible that you have to "take ownership" of the directory in question. Google
"take ownership" if you don't already know what that's all about. Other than that, it
may be worth it to get the beta VDH. I have been using it since Michel posted it & it
has never given me any problems.

[jcv...@gmail.com]

same for me, video downloads well, that's why it's complicated to debug, it depends on the local machine.

about the code, no C++, JavaScript : https://github.com/mi-g/vdhcoapp

jerome