Skip to main content

Hello,

I have been receiving the error message: “The process cannot access the file because it is being used by another process” related to a txt file that I am using to log my bot’s progress. As my bot runs, this text file is updated using the “Log to file: Log to txt file” action. I have no other instances of this text file open and no other applications are using or referencing this text file (that I know of), so I have no idea why it would say that the file is already being used by another process.

I have been logging using this same method for weeks on the same project and I have not received this error message. However, today I have received this error almost every time that I have run my bot. I thought that the issue might be coming from situations where I have two consecutive “log to file” actions in my bot and so I added a delay in between those actions. This worked in these cases, but I have other cases where there is a single log to file action that is still failing.

Note that the txt file is named using a time stamp. For example, it might be named myAuditLog_2024-07-29_15-26-47 so that no two audit logs have the same name. Could this be the result of a recent update?

 

Any insights are greatly appreciated. Thank you.

 

 

we’ve run into this unfortunately as well when writing to log files on a shared drive hosted on a windows server… curious if you are also writing to a file on a remote drive in this case?

the only way to work around the issue that we could figure was to redesign our logging framework (which had been performing fine since back in v10.x) to have each bot runner write to a log file on their local HD, and then map those local HDs as network drives to our admin/support staff PCs so they can monitor/review the log files that way. we see this issue only once in a blue moon now (vs constantly all day when writing to the share drive), so it sort of “works” for us, but it’s far less ideal than a centralized drive with the log files for each bot runner device in one place….

we had no issues writing to files on the share drive with the same or more volume of data via powershell or python scripting executing from the same bot runner devices where this bug was occurring in AA360. seems reasonable to conclude it’s a bug with the “log to file” action where it allows for collisions writing to the same file from a single taskbot thread. AA support sadly wasn’t helpful in providing a resolution to this for my org and we ended up living with the workaround described above. Hoping someone will have some different experience or insight here!

we’ve run into this unfortunately as well when writing to log files on a shared drive hosted on a windows server… curious if you are also writing to a file on a remote drive in this case?

the only way to work around the issue that we could figure was to redesign our logging framework (which had been performing fine since back in v10.x) to have each bot runner write to a log file on their local HD, and then map those local HDs as network drives to our admin/support staff PCs so they can monitor/review the log files that way. we see this issue only once in a blue moon now (vs constantly all day when writing to the share drive), so it sort of “works” for us, but it’s far less ideal than a centralized drive with the log files for each bot runner device in one place….

we had no issues writing to files on the share drive with the same or more volume of data via powershell or python scripting executing from the same bot runner devices where this bug was occurring in AA360. seems reasonable to conclude it’s a bug with the “log to file” action where it allows for collisions writing to the same file from a single taskbot thread. AA support sadly wasn’t helpful in providing a resolution to this for my org and we ended up living with the workaround described above. Hoping someone will have some different experience or insight here!

Thanks, I ended up doing pretty much the same thing. As the bot runs, it creates and audit log file on my local PC and updates the audit log file there. At the end of the bot’s execution, that audit file is copied to the project’s directory in a network folder.

I read through some other similar issues and it looks like this error most often occurs when writing to a txt file on a network folder, so the best solution is to write to a desktop txt file and then upload that file at the end of the bot’s execution.

 

Reply


Terms & ConditionsCookie settings