Read Text File action can't read files open by another process

The "Read Text File" action wants to open a file for generic read with no sharing.  This means if the file is open for read by another process, the action will fail.  Can you make it an option (or change it outright) so that the "Read Text File" action opens the file to allow read sharing?  As it is, we have 90 seconds of retries in place waiting for the other process to close the handle so that FB can read the text content.  This is not ideal.

A post from last year indicates that the action was fixed, but apparently it isn't working like that any more.

Process monitor shows a SHARING VIOLATION error when attempting to open the file:
Desired Access: Generic Read
Disposition: Open
Options: Synchronous IO Non-Alert, Non-Directory File
Attributes: N
ShareMode: None
AllocationSize: n/a

Share Mode should probably be at least "Read" if not "Read, Write"

We are using FB v7.0.0.864.

Thanks,

John Gonyo

Hi John,

I’ve updated the ‘Read Text File’ action to allow shared reading. I’ll let you know when a test build is available.

Regards,
Paul.

Hi John,

Here is the new test build of FinalBuilder which has an option to allow shared reading of files.

URL: https://www.finalbuilder.com/downloads/finalbuilder/aex6/FB700_903.exe

Regards,
Paul.

Thanks for the quick turn-around! However, we the new version (v903) created a new failure.  It has an unexpected failure with pushing an item onto a Queue.

We define the queue (ActiveFolders) in the main action.  Later, in an async action, we push items onto the queue.  It seems to successfully push 20+ items onto the queue, then suddenly it fails stating:

List object not found: ActiveFolders
Let me know if you need more information.  We had to roll back to v864.  John 

Hi John,

Thanks for reporting this problem, I’ve been trying to reproduce it here but haven’t had any luck. Are you able to send in a project to support [at] finalbuilder.com which reproduces the bug you’re seeing?

Regards,
Paul.

Hi John,

Can you just confirm whether in you're project you are calling a Action List recursively with an ASync Group? This has been the only way so far to reproduce the error you're getting.

For example:

- Main Action List
  - Define Queue
  - Run Action List (List1)

- List1 Action List
  - Push onto Queue
  - Run Action List (List 2)

- List 2 Action List
  - Async Group
    - Run Action List (List 1)

Regards,
Paul.

I looked closely at the project, it’s not recursive. I was unable to reproduce with a sample project. So I stripped the project down to the basics and was able to reproduce it. When I change the “main” project’s async action to synchronous, I don’t get the exception. I’m trying to isolate it in our project file so you can reproduce.

-john

Try #2 (last post messed up):
I trimmed our project down to the bare necessities to reproduce the failure.  It occurs during "ASync - Stage Service Files By Machine" down inside 2-3 levels of action lists during the "Stage Service Files" action list.  It doesn't happen every time, but most of the time.

Hopefully this can help you resolve the issue we're having. 

Thanks!

John

Hi John

Please try this build, it should now work as expected. The issue was caused by code we added in the last update to deal with objects (such as queues, filesets, property sets, ftp connections etc) being defined in a cloned actionlist - when more than 1 instance of an actionlist is run at the same we clone the actionlist and run the cloned one(for re-entrance reasons). We have made some improvements to this over the last few days.

We created a bunch of new tests which showed the issue you were seeing in various scenarios, and found a few other failures too (although some were in somewhat contrived situations), all those tests are now passing so hopefully we have it sorted :

https://www.finalbuilder.com/downloads/finalbuilder/aex6/FB700_913.exe

Vince, 

We've been running build 913 for a week now and haven't seen any new issues crop up.  The flag to toggle sharing on file reads works just great for us!

Thanks again,

John

Hi John,

Thats great! Thanks for letting us know.

Regards,
Paul.