Can Not Copy Resource / The system cannot find the path specified

[ravenRpg38]

I have tried several times to run Texgen and each time I get cannot copy resource textures\dungeons\impextwall01_n.dds to my disc drive where the output where dyndolod is stored. "the system cannot find the path specified"

[DarkladyLexy]

i had some users do that Z and still have issues

[z929669]

33 minutes ago, DarkladyLexy said:

i had some users do that Z and still have issues

It's always possible that OS updates will throw a wrench into things. I get them and haven't seen this issue, so it could be UAC if install path is in "Program Files", etc., or that I have disabled Windows Security and Defender (I use ESET) ... not at home now to verify, and I forget.

As you know, some people say they do things but they don't actually do them correctly or jump to conclusions ... or there is some other related issue with their setup. I find this post to be the best procedure to share:

... I may just add this to our guides as well.

[DarkladyLexy]

well just had this for thw first time I have exceptions in place i haven't update Windows and MO2, Steam and all Skyrim tool are outside of UAC. It odd thsi happen now

[DoubleYou]

I have exceptions in place. Just successfully generated without any issues.

[matashina]

Hello, I'm trying to get LOD'd up again after wiping the entire hard drive I had SSE installed on. I have two questions:

1. The first time I ran TexGenx64, I was getting 

Can not copy resource textures\clutter\stockade\stockadewood01_n.dds to C:\Modding\DynDOLOD\TexGen_Output\DynDOLOD-temp\textures\clutter\stockade\stockadewood01snow_n.dds The system cannot find the path specified.

The file in question was right there in my data folder, naturally, not even in a BSA. Yes, I know that this is because of firewall/antivirus stuff for most users! For me, though, turning off Windows Defender didn't seem to help like it did for others. What allowed me to finish the program was deactivating DynDOLOD Resources 3.0 from my load order before I ran TexGen. Here are logs for the successful run: TexGen_SSE_Debug_log TexGen_SSE_log. I can also try rerunning with the resources activated if that output would be helpful.

Was I supposed to be running TexGen without the resources activated this whole time? If not, does the fact that I had to deactivate the resources to get the program to work evidence of something wrong that I should fix?

2. Having (maybe) run TexGenx64 to completion, I moved on to run DynDOLOD for the first time on this machine, and it's taking way way way longer than I'm used to, at least 4 or 5 hours where it used to complete in like 45 minutes. I went to bed last night with it running and when I got up this morning it was still running. I exited th eprogram because I was worried it was taking so long (probably shouldn't have done that). Here are all the DynDOLOD/Lodgen log from that run, hope it's okay I zipped them.

Is it normal for it to take this long? The only thing I think I had different in my settings from my old setup on the same hardware is changing my tree rules to the ones recommended in the new Aspens Ablaze DynDOLOD add-on.

Thank you as always and I hope to god I didn't miss any necessary logs. There currently is no bugreport.txt.

[sheson]

On 9/28/2021 at 7:17 PM, matashina said:

Hello, I'm trying to get LOD'd up again after wiping the entire hard drive I had SSE installed on. I have two questions:

1. The first time I ran TexGenx64, I was getting 

Can not copy resource textures\clutter\stockade\stockadewood01_n.dds to C:\Modding\DynDOLOD\TexGen_Output\DynDOLOD-temp\textures\clutter\stockade\stockadewood01snow_n.dds The system cannot find the path specified.

The file in question was right there in my data folder, naturally, not even in a BSA. Yes, I know that this is because of firewall/antivirus stuff for most users! For me, though, turning off Windows Defender didn't seem to help like it did for others. What allowed me to finish the program was deactivating DynDOLOD Resources 3.0 from my load order before I ran TexGen. Here are logs for the successful run: TexGen_SSE_Debug_log TexGen_SSE_log. I can also try rerunning with the resources activated if that output would be helpful.

Was I supposed to be running TexGen without the resources activated this whole time? If not, does the fact that I had to deactivate the resources to get the program to work evidence of something wrong that I should fix?

2. Having (maybe) run TexGenx64 to completion, I moved on to run DynDOLOD for the first time on this machine, and it's taking way way way longer than I'm used to, at least 4 or 5 hours where it used to complete in like 45 minutes. I went to bed last night with it running and when I got up this morning it was still running. I exited th eprogram because I was worried it was taking so long (probably shouldn't have done that). Here are all the DynDOLOD/Lodgen log from that run, hope it's okay I zipped them.

Is it normal for it to take this long? The only thing I think I had different in my settings from my old setup on the same hardware is changing my tree rules to the ones recommended in the new Aspens Ablaze DynDOLOD add-on.

Thank you as always and I hope to god I didn't miss any necessary logs. There currently is no bugreport.txt.

The "file in question" is the destination path that can not be written to, because the OS, UAC, anti vir, or another process blocks write access.
C:\Modding\DynDOLOD\TexGen_Output\DynDOLOD-temp\textures\clutter\stockade\stockadewood01snow_n.dds

DynDOLOD Resources contain LOD assets for LOD generation with DynDOLOD. TexGen generates LOD assets from full models/textures to a new and empty output folder outside of the game and mod manager folders. Hence for this error message it does not matter at all if DynDOLOD Resources are installed or not when running TexGen - if the instructions are followed correctly.

I suggest to pay at least some attention to log messages and read the help file what they mean. https://dyndolod.info/Messages

It seems you are trying to generate grass LOD. Something seems off with the grass  cache files. Did you use the new scale setting by any chance?

[z929669]

@sheson You may already have plans to address this, but I bet you are more weary than I am of seeing questions about "The system cannot find the path specified" and the resulting assumption that it is a TexGen or DynDOLOD application issue.

If you have some method of detecting the probability of the cause, a simple error message change should avert/assuage at least half of these erroneous assumptions/conclusions. Perhaps this is a general OS message over which you have little/no control, but it is doing you a disservice ...

"cannot write to the specified path, due to some process that blocks write access" (maybe even worth months/years arguing with MS support to improve their generic messages)

[DarkladyLexy]

sometime time it generates without issue sometime is doesn't it all so random.

 

Edit I have exception in place and i hit the error. Thing is i have generated DynDOLOD and Tex several time toiday without issue.

[z929669]

40 minutes ago, DarkladyLexy said:

sometime time it generates without issue sometime is doesn't it all so random.

 

Edit I have exception in place and i hit the error. Thing is i have generated DynDOLOD and Tex several time toiday without issue.

I believe the problem is that there are > 1 causes for this rather generic error. It's either the 'security'-based issue (which you have resolved via Windows Security exception(s)) or one or more other problems that are possibly more (or no more) syntactically accurate with respect to that terrible error message. In other words, I think it could also be a bad texture, NIF or other file-related issue. This would explain why it happens seemingly at random.

I would post logs and bugreport.txt if you have them (tip: delete logs after last good run so that each log is only as long as last run).

Also, a reboot can resolve in some cases ... see best answer on this topic

[sheson]

On 9/28/2021 at 8:58 PM, z929669 said:

@sheson You may already have plans to address this, but I bet you are more weary than I am of seeing questions about "The system cannot find the path specified" and the resulting assumption that it is a TexGen or DynDOLOD application issue.

If you have some method of detecting the probability of the cause, a simple error message change should avert/assuage at least half of these erroneous assumptions/conclusions. Perhaps this is a general OS message over which you have little/no control, but it is doing you a disservice ...

"cannot write to the specified path, due to some process that blocks write access" (maybe even worth months/years arguing with MS support to improve their generic messages)

I already did this. Many months ago, by adding "Help for this message" opening a help page which explains:

"The last part of the message contains the error message from the OS.
The system cannot find the path specified typically means the OS, UAC, antivir or some other 3rd party crap ware is blocking write access to the mentioned destination path. Add an exception to whatever it is that is blocking access.
Remove old files from the destination/output path, which might prevent creating the new files because they are blocked by other programs etc."

The OS does not tell the program a specific reason for why it was denied write access, beyond the error message returned.

[sheson]

The reasons and explanations are given in the Help for this message link. 

"The system cannot find the path specified typically means the OS, UAC, antivir or some other 3rd party crap ware is blocking write access to the mentioned destination path. Add an exception to whatever it is that is blocking access.

Remove old files from the destination/output path, which might prevent creating the new files because they are blocked by other programs etc."

The help also includes troubleshooting instructions to double check the source file and manually copying it with xEdit. It is not a bad texture or NIF.

Use Copy this message to clipboard instead of posting screenshots.

[DarkladyLexy]

i have done all that I've added exceptions none of tools or MO2 is in a UAC I have check xEdit. the only way i can get TexGen run lately is turn off Windows defender real-time protection run Texgen the turn it back on aftrewards

[sheson]

One would think that such a program has a log (e.g. Windows Event log) in order to check what and why it does things in order to know what type of exception to add.

Add exceptions for every program involved. Mod manager, TexGen, DynDOLOD, Texconv, LODGen etc.

Add exceptions for commonly used file types, like esm, esp, esl, bsa, ba2, nif, dds etc.

If such a program does not work properly, maybe remove it permanently.

That is all the support I can give for third party crap ware like Windows 10 and its tools.

There is nothing a simple program  like TexGen/DynDOLOD/FNIS/Nemesis etc.  can do about third party crap ware preventing write access.

This problem/error message keeps happening since years and comes and goes with daily anti vir updates.

https://www.reddit.com/r/skyrimmods/comments/pwzfig/psa_windows_defender_has_recently_started_giving/
https://www.reddit.com/r/skyrimmods/comments/pgvwz9/psa_for_those_of_you_getting_nemesis_unlimited/
https://www.reddit.com/r/skyrimmods/comments/pi19zp/skyrim_crashing_due_to_windows_defender/
https://www.reddit.com/r/skyrimmods/comments/pmbdja/nemesis_error_6002_file_1st/
https://www.reddit.com/r/skyrimmods/comments/pr2ytn/nemesis_and_fnis_have_suddnely_stopped_working/

[DarkladyLexy]

the odd thing is this only started happen since I updated to Alpha 44

[sheson]

What probably happened is that it stopped working after a daily Windows Defender update. As you can see from the linked posts above, Windows Defender regularly causes problems.

It is almost impossible to help or provide support simply being the innocent victim of 3rd party crap ware, but here are some common sense tips:

Since disabling Windows Defender lets the programs work properly it is clear that the only thing that is broken is Windows Defender.

It seems Windows Defender blocks the writing of a texture. Maybe the source texture changed and its content is what triggers the false positive.

If Windows Defender blocks valid programs/things add an exception. If adding exceptions doesn't work, Windows Defender is broken or the exception is not matching. Hence the suggestion to check the Windows Event log to learn what actually triggers the false positive.

 xEdit/TexGen did not change in several years how it uses standard OS function to read/write files. The compiler did not update in several months.
In case Windows Defender flags on some random byte order in TexGenx64, test with this version.

I suggest to get rid of problematic crap ware like Windows 10 or its broken tools like Windows Defender or to notify the developer so they can fix it.