I have a custom created add-in to handle moving files based on card variables, using the IEdmFolder6.Move method. 99% of the time it works fine, but every once and awhile I'm getting a failed task. I've finally narrowed down the exact scenario as described below.
If UserA manually moves a file (drag/drop, cut/paste) from FolderA to FolderB and then UserB tries to run the task which would move the file from FolderB to FolderA. The task fails. The error generated is "An attempt was made to create a new file or folder with the same name as an existing one." Which is because we do not allow files with the same name in our vault, but I'm moving a file not creating one...
I've confirmed this only applies to a task (created from the custom addin). If I do this from a stand alone application the issue does not exist.
Actually, I just tried this again and I must have not tested correctly the first time around because this doesn't work from an external exe either.
Also, oddly, if prior to executing the task UserB browses to FolderA in the vault, then runs the task. The task runs successfully. Based on that, it seems as though their needs to be some kind of refresh the task needs to do because that file location isn't getting updated after it's moved by someone else. But why it only applies to a task/addin and not the stand alone application I don't understand.
I've actually run into this exact issue before but it was with the creation of folders behaving the same way, created on one computer but unseen on another (from the addin's perspective) unless the parent folder was browsed too. In that case it was solved by using a batchadd which must do some kind of magic.
So I'm not really sure what I'm suppose to do here.
VAR was able to track down a workaround. I'll just quote it because I can't really explain it.
Anyway, checking for a local file with the same name as my source file in the destination folder and renaming it allows me to move my vault file and there is no junk file left over. *shrug*
UPDATE 8/15/2016
I ran into this issue again with a PDF creation function I have for dwg files. The software thinks the file is there as read-only and won't overwrite when no file exists. I did some more testing I discovered what I think is the root cause. When files are deleted in PDM they still exist in the deleted items of the folder properties.
If you call IEdmFolder7::DestroyDeletedItems, System.IO.File.Exists will return false. The only downside is the method destroys everything in the folder, you can't specify a single file.
You can try it yourself with the below code if you so wish. Create a file in the vault and close your explorer window. Run the function on the file path. You should find the vault file and get a local copy. Then from a remote or 2nd computer delete the file from the vault. Run the function again and it will not find the vault file but the windows api will still see a file. Uncomment one of the methods and it should correct it so windows doesn't see the file anymore.
I like the destroy method because it makes more sense to me as to why it's happening. When using the System.IO.File.Move(fpath, path & "Temp" & name) method it's a magic ether file as far as I can tell and have no clue what, if any, problems it may cause.
This was on Windows 10 and EPDM 15.2