Glenn Posts: 99 03/08/2015	Glenn Posts: 99 I just had another inspiration for a use of SyMenu, while writing my previous question... I have one project that I share on dropbox... one dropbox folder has a number of programs installed, and for each of several instances of the project there is a data folder. If this project grows big enough that I use more space than in available on free dropbox (and it is heading that way), I'll make the project programs folder read-only to others. Right now, others are just "cooperating" to make it read-only. So if I install SyMenu for this project, that would allow all the users to benefit... but if I put it in the programs folder, it might become read-only, like the CD/DVD question I posed yesterday. On the other hand, if it is customized for a particular instance of the project, and placed in the data folder, there is still the possibility of multiple people working on that instance wanting to use SyMenu concurrently. I realize that this isn't the "design goal" for SyMenu, but am wondering if it might work in such a scenario?
	link
Glenn Posts: 99 03/08/2015	Glenn Posts: 99 Having just commented in my read only media thread, after having found a reference from version 3.04 release notes, I wonder if "multi user mode" might be possible by "simply" configuring SyMenu to _think_ it was running on read-only media, even if it is a read-write dropbox folder. And, as a corollary, I wonder if SyMenu detects "read only dropbox folders" (but I don't have any to test with, and I'm not sure how I'd know if it detected it, if I had one!)
	link
Gianluca Administrator Posts: 1274 03/08/2015	Gianluca Administrator Posts: 1274 Well I'm not sure if I've understood everything well but the reply is yes. From the next version (4.12) SyMenu switches in read only mode whenever it checks that it has no permission to write new files on its folders or it has no permission to modify its files. If I'm not wrong a Dropbox public share prevents the guests to modify existing files. In this case your configuration will become possible.
	link
Glenn Posts: 99 03/08/2015	Glenn Posts: 99 There are 3 kinds of Dropbox sharing that I am aware of, but have only experienced #1 and #3 below so far. 1) Read-write sharing among a group of cooperating users, all synchronizing in read-write modes, but there is a delay from a file getting updated by user A and seen by user B (and C, etc). And Dropbox maintains old revisions for 30 days, so if there was a conflict, and it is noticed soon enough, manual resolution can be done. 2) Read-only sharing among a group of cooperating users, a paid feature, which I haven't experienced. I would assume one writer and many readers, in which case the readers see read-only. If it is possible to have multiple writers in this mode, I would assume they would synchronize as above. 3) Public URL. No automatic synchronization is done. Users with the link can download, and can share the link further. Downloading makes their own copy read-only or read-write, but it is their copy or fork and does not affect the data at the link.
	link
Glenn Posts: 99 03/08/2015	Glenn Posts: 99 So it sounds like sharing mode 2 will work great with the improved read-only detection. Sharing mode 3 works today, because it is a private copy. Sharing mode 1 is the remaining question here, I think. Where each person has a read-write copy, but may be using SyMenu concurrently, even if carefully updating different files in a cooperative manner with other users. Here is where a configuration setting that says "pretend to be read-only" would be useful, or else very careful updating in SyMenu to deal with concurrent access/update to the SyMenu working data.
	link
Gianluca Administrator Posts: 1274 04/08/2015	Gianluca Administrator Posts: 1274 I think that sharing mode 1 is quite impossible to support for SyMenu both because of the DropBox delay and because of SyMenu works as a single user application. I give you a simple example. Working as a single user application means that during the configuration SyMenu works with an in-memory folder structure image until the user saves it on the disk. But when the user saves the new configuration he could overwrite a previous modification already committed by another user. Unfortunately SyMenu is not born with a concurrent scenario in mind. I completely agree with your analysis regarding the sharing mode 2 and 3. With the next version even the sharing mode 2 will become possible.
	link
Glenn Posts: 99 04/08/2015	Glenn Posts: 99 I'm not surprised that SyMenu keeps data in memory for better performance while operating, thus making Sharing mode 1 problematical. But one way to support sharing mode 1 would be to have a configuration item that causes SyMenu to pretend it is in a read-only environment.... except for one computer that is allowed to read-write. The name of the computer would generally suffice, as we are talking cooperative users here, if they are allowed read-write access to the dropbox folder, and it is unlikely that two users would have the same computer name. But for extra protection, it could be computer name and user name combined, which would more rarely coincide. The computer name (and user name) could be automatically determined when that user sets the read-only mode for others.
	link
Gianluca Administrator Posts: 1274 04/08/2015	Gianluca Administrator Posts: 1274 Practically you are proposing to put SyMenu in charge to manage the permissions that Windows already manages on its file system. Well I think SyMenu is yet too young to replace Windows with this task too. Do we want to leave Windows in charge to do something or not? Let's concentrate the SyMenu features, and consequentially my efforts, on its core tasks instead. If you use a file system (DB, Win or whatever) that allows you to give the write permission to certain users and only the read only permission to others, you have already a certain degree of flexibility in SyMenu too. Indeed the concurrency problem remains. If your file system isn't able to be so granular in assigning the permission you can change your approach. Just trying to give you a suggestion. Why not duplicate the SyMenu root folder and share the first one with the write enabled users (mode 1) and the second one with the read only ones (mode 2/3)? Naturally to maintain the two folders synchronized you should create a synchronization task, among the first one to the second one. I don't know if Dropbox could have problem with this further method, but you can try to create a symbolic link from the root folder instead of a real copy. In that way you have no need to synchronize the folder too. Well pay attention to the symbolic link because every file deleted on the symbolic folder is deleted on the root too. If you test these configuration I'll be very grateful to you if you can share your experience with us.
	link
Glenn Posts: 99 04/08/2015	Glenn Posts: 99 Oh, no, not at all. I'm not at all suggesting that SyMenu would manage the permissions of the Windows file system. I'm only suggesting that SyMenu have a configuration method to enable a mode that is already necessary for the support of read-only media, wherein SyMenu disables its own features that would require writing to the files that it manages for its own use. The result of enabling that mode for SyMenu on shared read-write media is that one person would be able to configure SyMenu for a particular purpose or usage for the environment that is shared in the read-write media, and that others could use the pre-configured SyMenu in that environment without having SyMenu garble its configuration file by having multiple instances of it writing back files to the shared media. Your suggestion of sharing a copy of a particular preconfigured SyMenu environment on read-only media assumes that it is possible to share read-only media together with read-write media. With Dropbox, creating read-only media costs $100/year, not an onerous amount, perhaps, in a commercial environment, but I am not in a commercial environment. I suppose there are two different implementation techniques that could be used to implement support for SyMenu on read-only media: The first would "detect" (somehow, not exactly sure your what techniques are being used or how, from 3.04 onward) and set a global mode that prevents operations that would eventually cause SyMenu to wish to write data to the disk. From your description of putting padlocks on certain operations, it would seem that this is the technique that you chose. I'm only suggesting that an additional mechanism be added to the detection, to set that global mode based on a configuration setting. The second technique would simply ignore the errors that occur when writing to media, but that would potentially ignore errors caused by other reasons than read-only media. It would also result in users being able to think they have performed certain operations, but that the effect of those operations would be transient, and vanish when SyMenu exits. Depending on whether any operations of SyMenu involve writing to the disk prior to exiting, the effects could be perceived sooner than at exit time, and be confusing. I doubt you have chosen this technique.
	link
Gianluca Administrator Posts: 1274 04/08/2015	Gianluca Administrator Posts: 1274 To reply to your legitimate doubt (there is no documentation for this feature) I'm using the first method: I try to intercept all the write operations to avoid them when SyMenu operates in read only mode (ROM). If an error occurs because of a write operation with SyMenu in ROM, means that I have to modify the code to intercept that writing too. No write operation is allowed with SyMenu in ROM. If your need is only to force SyMenu in ROM regardless to the user currently logged, well it's a trivial feature and I can implement it yet in the next version. I can check the existence of one certain file inside the config folder (for example an empty file called READONLY). If SyMenu finds the file it slips in ROM. Why not putting the option into the configuration? Because you can't change it anymore after setting it because SyMenu will always starts in ROM and avoids further configuration. What do you think?
	link
Glenn Posts: 99 04/08/2015	Glenn Posts: 99 Thanks for your continued attention to my suggestion. The existence of a file such as READONLY to trigger ROM would be sufficient. While any user actually on read-write media could remove that file, _any_ solution that depends on _any_ configuration setting to trigger ROM on read-write media would be subject to replacement of the file containing the configuration. There can be no prevention of an "attack". But this, or any configuration scheme, would avoid the situation where users accidentally modify a shared configuration of SyMenu that other users are depending on having in a stable state, and this would avoid surprises for the other users. Regarding a configuration item, I note that you have "auto execute" items that only run on certain computers. A readonly configuration setting that retained the computer name (and maybe user name), of the person that set the option, and only entered ROM for other users, would allow that one user to conveniently edit the SyMenu configuration for the other users. Of course, that one user could have a second SyMenu configuration stored elsewhere that could be edited, as you pointed out, and being on read-write media in actual fact, the shared configuration could then be replaced by updated one. This would be more cumbersome, but would also ensure that the one user also doesn't accidentally make changes that affect others.
	link
Gianluca Administrator Posts: 1274 04/08/2015	Gianluca Administrator Posts: 1274 Your second proposal makes perfectly sense but my point is to implement a workaround yet in the next version and not to give you a promise for the 2018 versions The read only mode based on the flag file is a simple and fast solution and I can implement it in hours so you'll have it for the 4.12. The security is certainly not a SyMenu problem. SyMenu is indefensible by definition because it works with files that are opened, not hidden, not crypted, not protected with password. The only way to create a not modifiable version of SyMenu is to entrust the security to Windows. And we return to one of our current topic.
	link
Glenn Posts: 99 04/08/2015	Glenn Posts: 99 "... you'll have it for the 4.12."
	link

---