Files switch to Read Only

[Guest]

I am using zeus on a WinXP Professional, editing a source file that is stored on a SCO server. I access the souce on my XP via a samba share.

Many times when I go to save the file, I notice a pause (sometimes very long), and then the already open file will switch to Read Only. I then cannot save my changes (unless I save them to another location).

I must then re-open my original source and re-apply the changes.

This behavior happens very regularly, but I have not found any specific patteren.

"About Zeus for Windows" reports my version as 3.93d

I have had to stop using zeus because of this behavior.

[jussij]

When Zeus opens a file it loads it into memory. Periodically it will check the status of the file to see if it's status has changed. It is this checking that controls the R/O state as shown in the status bar and in the file caption. For example if you open a dummy c:\temp\test.file then use the command line prompt to delete or rename the file, when you switch back to Zeus you will see this behaviour.

Many times when I go to save the file, I notice a pause (sometimes very long)

The fact that the save is taking a long time hints that Zeus is having troubles seeing the file. At a coding level Zeus uses nothing but standard Windows file API's to open, read and write the files. But when it comes to networking and Windows there does seem to be a bit of a black art to making it work

For example, there have been at least two reports of very slow file loading and saving for Zeus connecting to files located on network machines running Novel and Lantastic. Unfortunately these same problems do not seem to appear when Microsoft networking protocols are used

and then the already open file will switch to Read Only. I then
cannot save my changes (unless I save them to another location).

The fact that the file status changed to R/O suggest to me that somewhere during the save process Zeus made a call to access to get the file read/write state and it returned either a file not found or a file read only result. This would have then triggered the change in status as seen in the status bar.

With the software you are using in place of Zeus, do you ever get errors reported when saving the file

What happens if you use the Zeus, File Save As menu

What happens if you use the Zeus File Read Only menu option This should force Zeus to check the file state a second time and if Zeus finds the file, the status should change to read/write.

Do you use UNC file names (ie \\server\directory\filename) or is the location mapped to a drive letter

This might well be caused by some sort of strange bug in Zeus, but since I have no way to replicate this bug, unfortunately it is not easy to fix

If any other Zeus users reading this message have seen similar or dissimilar results while running Zeus and Samba any additional information would be most welcome

Cheers Jussi

[David Morris]

If any other Zeus users reading this message have seen similar or dissimilar results while running Zeus and Samba any additional information would be most welcome

G'day.

In the MonTel application that I develop, especially in the older days when we used the Jet database (rather than SQL) we sometimes had problems on Novell systems. These seem to come down to three basic issues, problems in the Novell client, File locking on the Server being handled in a different way to MS, and third party application (often a virus checker) getting in the way. All of these problems are environmental, which means there is not much you can do about it programatically, and usually an update of the system is required.

For some detail on this see: http://www.netwiz.com.au/appnotes/i2848.htm

The one thing worth looking at programatically is the (equivalent of) the Win32 CreateFile API DWORD dwShareMode setting. I have vague memories of reading that Novell being more fussy about this setting, and pehaps this is true also of the other systems mentioned. I have not really developed an definitive answer, since I cannot replicate the specific environments involved, and the problems have generally been resolved by OS updates.

There are a number of settings for file sharing that might be worth an experiment, for example:

fsopen (in c and the equiv):
#define _SH_COMPAT 0x00 /* compatibility mode */
#define _SH_DENYRW 0x10 /* deny read/write mode */
#define _SH_DENYWR 0x20 /* deny write mode */
#define _SH_DENYRD 0x30 /* deny read mode */
#define _SH_DENYNO 0x40 /* deny none mode */

Which doesn't seem to directly map to:

CreateFile (in the Windows API)

#define FILE_SHARE_READ 0x00000001
#define FILE_SHARE_WRITE 0x00000002
#define FILE_SHARE_DELETE 0x00000004

(Noting that dwShareMode = 0 is not in that list - but perhaps there are undocumented settings here?).

And see also the older OpenFile WIN32 API call which hints at the mapping between the two.

I know that this is not particularly definitive and therefore not especially helpful, but perhaps it might suggest a starting point. If this is solved I would be interested in hearing the answer.

regards DM

[Guest]

Sorry for the delay.

With the software you are using in place of Zeus, do you ever get errors reported when saving the file

I open a terminal session on my XP machine to the SCO box. Then I use vi. So I don't get any similar problems, but this is not relevant because I am editing directly on the SCO

What happens if you use the Zeus, File Save As menu

I can "Save As" to any local location. I have not tried "Save As" a different name to the original location.

What happens if you use the Zeus File Read Only menu option This should force Zeus to check the file state a second time and if Zeus finds the file, the status should change to read/write.

I did not know I could do that. I will try it next time the problem occurs, and let you know what happens.

Do you use UNC file names (ie \\server\directory\filename) or is the location mapped to a drive letter

We access internal network locations using UNC. We do not map to drive letters.

I noticed that when the switch to RO would occur, the icon in my workpace window related to the file would get a red line through it. In fact, all of the icons for all of the files in the workspace (which are all on the Samba share) would get a red line through them. It seems workspace is attempting to access in some way all of the files in the workspace (even though I have not personally made changes to them), perhaps to check for updates made outside of my session.

After seeing that common behavior, I closed my Workspace, and stopped using it. I now open my files directly myself with the "File Open" dialog, rather than accessing them through the workspace.

This seems to help a lot. In fact since I closed my workspace, and started opening the file directly, I have not seen the file switch to RO. Although on (rare) occasion the update fails, and gives a message in the status portion of the window. I prefer this behavior, as usually, I only need to re-save the file, and it works the second time.

Hope this additional information helps .

[jussij]

I have not tried "Save As" a different name to the original location.

I was actually thinking along the lines of using the "Save As" to save the file to the the same name and original location

I did not know I could do that.

Just use the File, Read Only menu. This menu will change the read only state of the current file. For the situation described I don't know what this will do, but it would be interesting to see if some sort of error is generated in the status bar.

I noticed that when the switch to RO would occur, the icon in my workspace window related to the file would get a red line through it. In fact, all of the icons for all of the files in the workspace (which are all on the Samba share) would get a red line through them.

Whenever a file in a workspace is saved an automatic ctags update is run by Zeus. The red line in the icon indicates that during this update Zeus was not able to open the file in question. Similarly at some time later when another update is triggered, the line will go away it Zeus does manage to open the file for the ctags update.

It seems workspace is attempting to access in some way all of the files in the workspace (even though I have not personally made changes to them), perhaps to check for updates made outside of my session.

For most of the files in the workspace all that is being attempted is to getting the timestamp of the file just to see if it has changed.

In fact since I closed my workspace, and started opening the file directly, I have not seen the file switch to RO.

That is very strange indeed. The workspace uses the same common file handling functions as the rest of Zeus so I would assumed it would work no differently to the rest of Zeus

My only guess is the workspace update is pushing the Samba file system too hard with too many file requests in too short a time and this is causing the failed result. To test this theory just re-open/re-enable the workspace but then use the Workspace Options menu, switch to the Tags section and untick the Enable the built-in ctags builder options.

This will stop the Workspace from checking the files for ctags changes, which should mean the instance of the switch to RO should also be reduced (ie you should no longer see these red icons).

Cheers Jussi