Feature Request - multi-user environment

[bestlion]

It would be nice if mboxviewer could create (Cache and etc. folders) and export files (Print To) to User related folders (userprofile\docs, app\temp etc.) Or possiblility to config "temp\cache path" To be able to use it in a multi-user environment

[zigm]

Next version will likely place all folders and files created by MBox Viewer under a single folder, say MBoxViewer, to eliminate "pollution" of the folder housing mbox mail files. Over time Mbox Viewer created many Cache folders. It might be doable to enable user to configure location of such folder. Currently the single root folder is created as C:\Users\UserName\AppData\Local\MBoxViewer when the mail folder is created on read-only media.

Currently MBox Viewer relies on Windows Registry to save and restore user configuration. What multi-user environment you have in mind? Will all users run on the same/single computer or separate computers?

[bestlion]

Thanks for expanation ! But what you described actually doesnt' work so for 1.0.3.25 ... and it caused trouble... I put .mbox file to folder what read-only for user, when user try make "Print To".. no any error and app show what it was done and show path to file in the folder (this read-only folder), where nothing was created (it not was created in C:\Users\UserName\AppData\Local\MBoxViewer)

Multi-users I meant - several users works on one PC

[zigm]

Thanks for an update. I assume the file path was something like C:\Users\UserName\AppData\Local\MBoxViewer\C\FolderName\PrintCache. The 'C' corresponds to the drive letter where mbox file resides under FolderName.

The testing I have done was with the CD drive. Let me know how did you set the folder as the read-only. Can I assume you created the folder under different account as the user ?

Enabling users to configure the target folder for MBox Viewer's data will not work unless MBox Viewer stops using Registry or Windows creates per user data in the Registry which would makes sense but I need to verify.

[bestlion]

It done just with read-only permissions on folder for userA

• Folder c:\test\ readonly permission for userA,
• PrintTo>html,
• "Created file c:\test\PrintCache\sample\xxxxx.htm",
• Open .. no so file

in C:\Users\userA\AppData\Local\ also no any folders related to mboxviewer

I think path to folder can be just stored like SMTP config (save it to C:\Users\UserName\AppData\Local\Temp\MBoxViewer\MailService\SMTP.ini) Or it can be just choice "for one user"\"for all users" and if first option selected always use C:\Users\UserName\AppData\Local\MBoxViewer for running out of confusion C:\Users\UserName\AppData\Local\MBoxViewer\mbox_filename\PrintCache

[zigm]

MBox Viewer seems to be confused. The folder doesn't seem to be read-only since MBox Viewer attempted to create file c:\test\PrintCache\sample\xxxxx.htm. Did MBox Viewer create any of sub-folders c:\test**PrintCache\sample**. Probably not.

"Folder c:\test\ readonly permission for userA," . How did you go about creating readonly permission for UserA.

Sounds like I need to create separate account for say UserA. Select Property on the target folder and go to Security option? Any other steps I should be aware? Would like to execute the same steps for my testing.

I believe MBox Viewer attempts to write dummy file to the target folder to determine whether folder/media is readonly. If the viewer can't create the file, it will assume that the media is readonly.

[zigm]

MBox Viewer check is not bullet proof. Actually it tries to create directory ".WriteSupported" in the folder with mbox file and remove the directory if the directory was created. If for some reason ".WriteSupported" directory still exists in "c:\test" folder, MBox Viewer will be confused. You may need to remove the ".WriteSupported" directory manually and redo the test.

[zigm]

I did some experiment with readonly folder and it worked correctly. I had problems setting the folder as readonly. Eventually I logged in as administrator and created F:/ROnly folder and installed mbox files. Next I gave access to UserA, see attachment. It worked fine as long as there was no ".WriteSupported" folder in the target folder. I had problems using Windows system calls to determine whether the folder is readonly so I decided to to rely on the create directory test. May need to review the approach but it seems to work, hopefully all the time.

Also, I checked that Windows creates per user configuration data in Registry so all should work.

Let me know if still have the problem you reported.

[zigm]

Hope you find time to help to resolve the reported issue. Not sure why we see different results. All my testing is done on Windows 10 Pro. It could be read-only folder configuration issue or something else. Appreciate any additional support you can provide to resolve the reported issue.

Thank You, Zbigniew