BUG:
I tried to rename a file but DOpus claims the file is in use. I clicked on another file in the folder to make sure the viewer was not holding on to the file and then tried the rename again. It failed.
I restarted DOpus and the rename succeeded.
A useful feature would be for DOpus, when a resource is locked (as in file rename), to display which process has a lock on the file.
What kind of file was involved?
A simple but large .json file (pure text) (about 381MB file)
It appears to be related to using the text viewer. When I display the file in the text viewer and try to rename it then the rename fails.
When I click another file in the folder so that the viewer should have freed up the file, the rename still fails.
Looks like the viewer is not releasing the file.
Problem does not occur if the text view pane is off
If you wait a few minutes after changing to another file, does it succeed then?
Could an antivirus scanner be taking a while to scan the large file when it's opened in the viewer, and locking it in place? (Not sure if any scan json data or take long to do so, but I've never dealt with such large json files before.)
Is this also happening with the latest version (12.6)?
Running version 12.6 x64 build 6369 6/9/2017 8:45:10 am
Windows 7 Ultimate x-64 with latest updates
yes
AV is not an issue... the file has been in existence for several minutes before I tried to rename it.
Opening files may cause an AV scan, even if they've existed for a while.
It's also possible something else is trying to view the .json file before failing and dropping through to the text viewer. It might be worth a try to disable all other viewer plugins to see if it makes a difference.
Does the file zip down to a reasonable size, and is it one that could be shared? I'd like to try with the same file to see if it happens here. If it does it should be easy to work out what's happening and why.
The problem DOES NOT occur if I don't have the file viewer enabled. It really has nothing to do with AV.
The file contains confidential personal information so I can't send it to you even if I could zip it down to something reasonable.
You should be able to create a big text file (does not need to be .json) and just fill it with random characters. Then you should be able to reproduce the problem. Its a bit of work but rather straight forward.
-David
I think I know the sequence that makes it fail.
I have a big JSON file for which I enable the viewer.
I run my program (which is trying to beautify the JSON file) which renames the file (adds a '.backup' suffix), and then reads from the renamed file to generate the original file name as beautified (nicely formatted) JSON.
When my program is done (I'm still developing/debugging the program), I delete the newly created (beautified) file (original name) and then try to rename the file with the '.backup' name back to the original name (so that I can repeat the whole process).
This is when it fails - consistently. I have to restart DOpus and then the rename works.
If I do the same process without enabling the file viewer, everything works fine.
I have not tried this sequence on a small file so I don't know if file size is the issue. My guess is that it is not related to the file size.
My intuition tells me that the problem is the the file the viewer is on gets renamed while the viewer pane is open to the file.
I just tried to rename the '.backup' file it to an entirely new name it works.
The problem only happens when I try to rename it back to the original name (which is what the viewer was originally opened to).
It very strongly suggests that the viewer did not release the lock it had on the file.
Finally, closing the viewer does not make the problem go away.. meaning the resource is never freed by the viewer when an external program renames its file while it is viewing it.
This should be enough to find this problem and fix it.
Which file are you viewing in the viewer? The one that is deleted or the one that you're trying to rename?
If you do everything the same, but close the viewer before deleting or renaming anything, does the problem still happen?
I ran the various tests again.. and here are the steps in a more concise scenario-based descriptions:
Sequences to reproduce issue:
Original file: a.json
[1] open viewer pane to a.json
[2] run program that
--- renames a.json to a.json.backup
--- creates a (now) new file a.json
--- program exits
[3] delete file a.json
[4] try to rename a.json.backup to a.json
==> Fails (file in use]
[5] try to rename a.json.backup to a.json.backup2
--- this actually works
[6] try to then rename a.json.backup2 to a.json
==> this still fails
CONCLUSION: there is a lock on the resource: a.json
The above scenario without the Viewer pane works fine
Scenario:
Original file: a.json
[1] open viewer pane to a.json
[2] run program that
--- renames a.json to a.json.backup
--- creates a (now) new file a.json
--- program exits
[3] CLOSE Viewer pane
[4] delete file a.json
--- this works
Scenario:
Original file: a.json
[1] open viewer pane to a.json
[2] run program that
--- renames a.json to a.json.backup
--- creates a (now) new file a.json
--- program exits
[3] Click on another file in folder so Viewer pane now displays an unrelated file
[4] delete file a.json
==> Fails (file in use)
CONCLUSION: there is a lock on the resource: a.json
=================================
Observation:
!! I don't think this has anything to do with AV
!! I don't think this anything to do with the file extension... it could easily have been a.txt instead of a.json.
As far as I can tell, all that's happening is that you cannot rename a file while it is being loaded into the text viewer.
If you delete a.json, then click a.json.backup, then wait until the viewer has loaded the file, the rename should succced, and does here.
I only see a file-in-use error if I click a.json.backup and then try to rename it while it is still being loaded back into the viewer. Since it's a 300MB text file, it takes a few seconds to load and process, and during that time the file is in use, so it cannot be renamed. But as soon as it is loaded, the rename should succeed.