File Stat Issue

[Jason.a]

In the Beta 2, Windows x64 version.  If a file is RW, and it becomes RO outside of the editor, the editor still thinks the file is RW.

[Clark]

Auto-reload only looks at the read only attribute on Windows. Are you changing the Read-only attribute (attrib +r <filename>)?

[Phil Barila]

Auto-reload only looks at the read only attribute on Windows.

You didn't really mean that, did you?

[Clark]

On Unix, we are able to do better because it's possible to check read/write status with a filename (access(filename,...)) . On Windows, we tried using win32 open calls but because the editor sometimes keeps file handles open (entire file not read or when file locking is on), SlickEdit thinks files are read-only that aren't.

[chrisant]

Oh, I see.  Here's how to fix that on Windows:

1.  Consider using FindFirstFile(fileName, &findData) and FindClose(), then examine findData.dwFileAttributes to get the file attributes.  This gets attributes without opening the file or using a file handle, it can't encounter a sharing violation on open/locked files.  CreateFile is also a notoriously slow API because of the amount of work it has to do, so using FindFirstFile might even yield a performance boost.

2.  If for some reason #1 is undesirable, another option could be to try using FILE_READ_ATTRIBUTES for the dwDesiredAccess parameter in a call to CreateFile (instead of using the broader GENERIC_READ).  Using FILE_WRITE_ATTRIBUTES certainly allows setting attributes on a readonly file, because the readonly attribute applies to content, not to metadata.  I don't know for sure if this approach will work (#1 definitely works), but it might be symmetrical, it might allow opening the metadata portion of a locked file.
CreateFile(fileName, FILE_READ_ATTRIBUTES, FILE_SHARE_READ|FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);

[Clark]

We are already doing #1. This is how we check the read-only attribute. This doesn't support fancy permissions though.

[Phil Barila]

1.  Consider using FindFirstFile(fileName, &findData) and FindClose(), then examine findData.dwFileAttributes to get the file attributes. 

An even better alternative (possibly) is FindFirst/NextChangeNotification().  See what's happening as it's happening.  Sweet stuff!

[chrisant]

We are already doing #1. This is how we check the read-only attribute. This doesn't support fancy permissions though.

The OP sounds like the only thing changing is the readonly attribute:  from set, to cleared.
FindFirstFile should be able to report the correct attribute state regardless of fancy permissions or open file handles or file locks (it can even inspect pagefile.sys which is basically always locked).

Is there something more going on in the OP's scenario?


And yes, FindFirstChange would be an ideal way to detect changes on Windows.  The editor wouldn't even need to poll anymore, which should solve the polling performance problem.  But this has been suggested a number of times over the years, so there must be other reasons why it isn't used (perhaps just the universal cost/benefit reason, familiar to every project under the sun ).

[Clark]

I looked into using a non-polling method. It doesn't work for removable drives (memory sticks etc.). You still need a backup method. In addition, there is no multi-platform solution. We decided to thread the polling instead because it handles all error conditions and it's a multi-platform solution.

[chrisant]

Ah, ok sure, the reasoning makes sense.  Threading solves the responsiveness problem (you're right it's a mistake to characterize it as a performance problem) and works across all platforms.

Back to the OP question, I guess I don't understand the explanation yet.  The OP stated that when clearing the readonly attribute outside of SE, the editor doesn't notice.  I think the response was that SE only looks at the readonly attribute.

Does that mean that the SE team has found cases where FindFirstFile reports the readonly attribute is cleared, but it's really set, and therefore SE ignores cases where the file appears to have become RW?  I don't think that's what you're saying, though, and I haven't seen that happen with my use of FindFirstFile (though I'm a bit sheltered by the nature of my corporate network).

[Clark]

I don't know what OP stands for.

The original complaint was that SlickEdit only looks at the read only attribute. At least thats what I understood. It always works.

[Phil Barila]

OP stands for Original Post(er).
I might have unintentionally derailed this thread, as I saw "Auto-reload only looks at the read only attribute on Windows." and jumped to the conclusion that referred to a lot more of the "auto-reload" functionality than it really meant, then jumped on the misinterpretation.
Sorry for taking us down a bunny trail.

[chrisant]

The original complaint was that SlickEdit only looks at the read only attribute. At least thats what I understood. It always works.

Have I misread the original post?  To me it says SE isn't noticing when files change from RW to RO outside the editor.  RW and RO are both the readonly attribute, so if SE only looks at the readonly attribute, then it should notice, right?

In the Beta 2, Windows x64 version.  If a file is RW, and it becomes RO outside of the editor, the editor still thinks the file is RW.

[Clark]

RW and RO on Windows is only the read-only attribute but I wish it supported all the fancy NTFS permissions. To a user, RW and RO should be based purely on whether the file can be written to and not just the read-only attribute.

[chrisant]

RW and RO on Windows is only the read-only attribute but I wish it supported all the fancy NTFS permissions. To a user, RW and RO should be based purely on whether the file can be written to and not just the read-only attribute.

One last try:

I get that.
The original poster complained that SE looks at the readonly attribute, and sees the wrong value of the readonly attribute itself.
The discussion about other kinds of access seems independent from the original report.

In the Beta 2, Windows x64 version.  If a file is RW, and it becomes RO outside of the editor, the editor still thinks the file is RW.

Jason, can you provide more detailed steps for how to reproduce the problem?