Xojo desktop app. Attempting to save/write to the.\Documents folder or any subfolder of .\Documents within the user profile fails with an access denied error 5. The application can save to every other folder (I have tried) within the user profile. .\Desktop, .\OneDrive, .\a-folder-i-created.
Running a built application as admin, running from the IDE, running from the IDE started as admin, no difference. I’ve tried using SaveFileDialog.ShowModal and FolderItem.ShowSaveFileDialog. No change. I’ve checked the folder ACL and it looks fine. The build and the profile is pretty much vanilla Windows 11 with the latest updates applied. No additional anti-virus, just Windows Defender.
Anyone else experienced/experiencing this? Any ideas to resolve it?
I am currently using an older Xojo 2020R2.1. Upgrading is not out of the question, depends whether the client will stand it, but I would need to be sure an upgraded Xojo will solve the problem.
//save msol output to file
var dlg As new SaveFileDialog, file As FolderItem
dlg.Filter = FileTypes.ftText
file = dlg.ShowModal
//super new way!
'file = FolderItem.ShowSaveFileDialog(FileTypes.ftText, "test.txt")
if file is nil then
Return
end if
var i as integer, outStream As TextOutputStream
try
outStream = TextOutputStream.Create(file)
for each line as string in pwsh1.Output
outStream.WriteLine line
i = i +1
next
catch err as IOException
MessageBox "IO Error " + err.ErrorNumber.ToString + " saving file " _
+ EndOfLine + err.Message
finally
outStream.Close
end try
MessageBox "Wrote " + i.ToString + " lines"
To remove Windows 11 “tricking you”:
try to save to Documents from any other application (excepted, of course, Xojo).
a.k.a. is your Documents folder mapped to Cloud in any way ?
No windows here, so no testing possible, but lots of reading and your trouble recalls me something.
Almost certainly not ‘the answer’, but are you running in a VM?
Is there any chance that you are saving to a ‘Documents’ folder which is not teh Windows one? (eg on my Mac VMs, I ‘see’ two document folders. One is Windows, and one is a mapped folder from the Mac
This may be more of a Windows permissions issue than a Xojo issue. I’ve experienced this on MacOS but not Windows. But it’s one of the reasons I’ve started saving in SpecialFolder.ApplicationData.Child(MyApp) instead of Documents, but of course this presents a problem for user-facing files.
If you still think it’s a Xojo issue I’d first try saving someplace where permissions allow, like ApplicationData, then using the shell class to copy it in place to the Documents folder (make sure to use the /y switch to overwrite an existing file, and always wrap filenames and folder names in Chr(34)).
Only my Xojo IDE and my Xojo apps that are having problems saving in the .\Documents folder.
Not a VM and not a redirected cloud drive. It really is very OEM. Windows 11, local admin account, Firefox, Chrome, MS Office, Powershell 7, VLC, Xojo, SQLite Studio and Beekeper studio. Is about it.
If this isn’t a known problem I will try to find another Windows 11 PC to try it on.
On Mac, saving and loading from Documents has become a pain due to iCloud.
It may be necessary to mess about with the NS calls I asked about in another post - (REALLY dont want to go there)
I just tried this code on my Windows 11 setup, and I can write happily using (almost) the same code
This is what I used, since I dodnt have the sourec data to write from:
Var dlg As New SaveFileDialog, file As FolderItem
file = dlg.ShowModal
Var i As Integer, outStream As TextOutputStream
Try
outStream = TextOutputStream.Create(file)
For x As Integer = 1 To 10 //CHANGED FOR TESTING
outStream.WriteLine Format(x,"0") //CHANGED FOR TESTING
Next
Catch err As IOException
MessageBox "IO Error " + err.ErrorNumber.ToString + " saving file " _
+ EndOfLine + err.Message
Finally
outStream.Close
End Try
returns a folder item, but Exists is false, due I believe to OneDrive being used. This could also happen with Documents. My solution was to present the user with a folder selection dialog if the target doesn’t exist.
That’s weird. Recently, I’m also having a problem with the Downloads folder for one of my users, in Windows 11.
Windows opens the file selection dialog by selecting the default folder (Downloads), but nothing is displayed, then the program freezes.
Opening all other folders works correctly for this user.
Opening the Downloads folder with another program (not made with Xojo) don’t exhibit any problem.
Try to open a file, it exists, it’s not nil, but the app hangs.
Try to save a file, it isn’t available to the system or .exists for a moment.
My app checks for a folder on startup. If it exists, it checks a file inside for a version number. if it is older, new files are unpacked.
Somewhere in that process, if the folder is under iCloud, sometimes the app just hangs. No error, no responses, just … nada.
Solution: delete or rename the folder and it gets recreated just fine.
I would assume that’s because, as you say, iCloud or similar is involved. Normally an I/O completes fairly quickly, so apps are going to work fine using synchronous I/O. But if the network is involved, an I/O can be started which looks like an ordinary I/O but which will be subject to timeouts or delays. The likes of TextOutputStream have properties and methods but no events.
Downloads would not normally be redirected to OneDrive unless the user has manually added the folder to Files on Demand. Documents is automatically redirected, along with Desktop and Pictures, when the OneDrive backup feature is enabled. Downloads is automatically redirected when Roaming Profiles are in use though.
On the general support side of my business I’ve seen multiple instances of Windows failing to properly revert OneDrive redirections when OneDrive is Unlinked, Uninstalled or the Backup feature disabled.
My gut feeling is my fault is either Xojo 2020 not playing ball with the Windows 11 common file dialogue, or a corrupt registry entry in the mess that is Shell Folders. I’m lacking the time to fault find Windows so for the moment the solution is.
Do you know about SpecialFolder. ?
It may be an alternative (save to Downloads and advertise the change ina MessageBox, so the user knows where the file resides.
Yes. Not new to Xojo or Windows. I’m as sure as I can be the fault is between the framework and the common dialogue.
The file is a document and I prefer to let the user choose where to save it. Documents is the natural choice but if it can not be saved there the user can have a second swipe and choose where they save it elsewhere.
The priority for the moment is releasing an initial build to the client. I can take another look at this once the pressure is off.
My Xojo app was built with 2020R2.1. Rolled out to the customer’s Windows 11 PC and is able to save to the Documents folder.
I am putting this down to some corruption in the user profile registry trees. Prime suspect is Zoom Rooms which was installed / uninstalled for a previous project I had forgotten about. At this stage it’s going to be quicker to re-create the user profile than continue to fault find.