- 31
- 10
- NAS
- DS418Play,DS218+,DS115
- Operating system
- macOS
- Windows
- Mobile operating system
- iOS
I am starting a new thread for this because it is a more accurate description of this issue than my previous thread about clearing the SMB cache to clear stalls when saving files.
Since the DSM 7.2 upgrade, the trick with clearing the SMB cache no longer unfreezes the apps concerned, which has caused me to look again at the issue.
Firstly, this problem now occurs on pretty much every save of a file to an SMB share from MS Word, Excel and Apple Preview on macOS. All software is fully up-to-date as of today.
At the root of the problem is that when you save a file to an SMB share, both apps create a folder at the same level of the share as the file you are saving. It has the name of the file with some apparently random characters appended to it after a dot, such as filename.ext.sb-12d3fc97-t7Wcfq, where the original filename was filename.ext. I am not entirely sure of the intended function of this folder, but it is at this point that the app stalls and you get the beachball. If you log on to DSM and delete the folder in FileStation then the save completes and the app comes out of its stalled state.
Word and Excel go one step further as they can create multiple folders and also what looks like a temporary file with the first two characters replaced with "~$". If you delete the folders AND the ~$ file the stalled app comes back to life again.
While these folders (and, for Word and Excel, the ~$ file) are sitting there in the folder the app will never come out of its stalled state.
There does not seem to be any permission issue with the shares, folders, or these folders and the ~$ file, but I cannot say for absolutely certain that this is not the issue. it is just that whatever I look at the permissions seem to be OK. I am however struggling to find out what else could be the cause of the blocking effect of these artefacts of the saving process. My guess is that if everything is working OK these should be created and then almost instantly deleted, but this is failing to happen and that is why the whole saving process hangs.
As I said, previously clearing the SMB cache fixed the problem, but that doesn't work any more. I also suspect that the SMB cache is not the cause of the problem, it was more that clearing the cache restarted Samba and that had the effect of almost coincidentally fixing the problem.
One other interesting thing is that Adobe Illustrator does not exhibit this behaviour when saving files and I nowadays never have problems with saving Illustrator files. This used to be a problem a few years ago but I think Adobe have fixed the problem, probably by modifying the way they save files. Microsoft and Apple have not.
Does anyone have any clue about this issue?
Since the DSM 7.2 upgrade, the trick with clearing the SMB cache no longer unfreezes the apps concerned, which has caused me to look again at the issue.
Firstly, this problem now occurs on pretty much every save of a file to an SMB share from MS Word, Excel and Apple Preview on macOS. All software is fully up-to-date as of today.
At the root of the problem is that when you save a file to an SMB share, both apps create a folder at the same level of the share as the file you are saving. It has the name of the file with some apparently random characters appended to it after a dot, such as filename.ext.sb-12d3fc97-t7Wcfq, where the original filename was filename.ext. I am not entirely sure of the intended function of this folder, but it is at this point that the app stalls and you get the beachball. If you log on to DSM and delete the folder in FileStation then the save completes and the app comes out of its stalled state.
Word and Excel go one step further as they can create multiple folders and also what looks like a temporary file with the first two characters replaced with "~$". If you delete the folders AND the ~$ file the stalled app comes back to life again.
While these folders (and, for Word and Excel, the ~$ file) are sitting there in the folder the app will never come out of its stalled state.
There does not seem to be any permission issue with the shares, folders, or these folders and the ~$ file, but I cannot say for absolutely certain that this is not the issue. it is just that whatever I look at the permissions seem to be OK. I am however struggling to find out what else could be the cause of the blocking effect of these artefacts of the saving process. My guess is that if everything is working OK these should be created and then almost instantly deleted, but this is failing to happen and that is why the whole saving process hangs.
As I said, previously clearing the SMB cache fixed the problem, but that doesn't work any more. I also suspect that the SMB cache is not the cause of the problem, it was more that clearing the cache restarted Samba and that had the effect of almost coincidentally fixing the problem.
One other interesting thing is that Adobe Illustrator does not exhibit this behaviour when saving files and I nowadays never have problems with saving Illustrator files. This used to be a problem a few years ago but I think Adobe have fixed the problem, probably by modifying the way they save files. Microsoft and Apple have not.
Does anyone have any clue about this issue?