Author Topic: File Stat Issue  (Read 2736 times)

Jason.a

  • Community Member
  • Posts: 5
  • Hero Points: 0
File Stat Issue
« on: May 03, 2013, 04:54:54 pm »
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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3941
  • Hero Points: 256
Re: File Stat Issue
« Reply #1 on: May 04, 2013, 11:02:50 pm »
Auto-reload only looks at the read only attribute on Windows. Are you changing the Read-only attribute (attrib +r <filename>)?

Phil Barila

  • Senior Community Member
  • Posts: 746
  • Hero Points: 61
Re: File Stat Issue
« Reply #2 on: May 05, 2013, 02:21:47 am »
Auto-reload only looks at the read only attribute on Windows.
You didn't really mean that, did you?

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3941
  • Hero Points: 256
Re: File Stat Issue
« Reply #3 on: May 05, 2013, 03:46:00 pm »
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.
« Last Edit: May 05, 2013, 03:48:06 pm by Clark »

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 131
Re: File Stat Issue
« Reply #4 on: May 05, 2013, 11:02:13 pm »
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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3941
  • Hero Points: 256
Re: File Stat Issue
« Reply #5 on: May 06, 2013, 12:51:31 am »
We are already doing #1. This is how we check the read-only attribute. This doesn't support fancy permissions though.

Phil Barila

  • Senior Community Member
  • Posts: 746
  • Hero Points: 61
Re: File Stat Issue
« Reply #6 on: May 06, 2013, 03:02:58 am »
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

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 131
Re: File Stat Issue
« Reply #7 on: May 06, 2013, 05:33:51 am »
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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3941
  • Hero Points: 256
Re: File Stat Issue
« Reply #8 on: May 06, 2013, 02:13:16 pm »
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.
« Last Edit: May 06, 2013, 05:24:46 pm by Clark »

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 131
Re: File Stat Issue
« Reply #9 on: May 06, 2013, 04:37:45 pm »
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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3941
  • Hero Points: 256
Re: File Stat Issue
« Reply #10 on: May 06, 2013, 05:09:59 pm »
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

  • Senior Community Member
  • Posts: 746
  • Hero Points: 61
Re: File Stat Issue
« Reply #11 on: May 06, 2013, 05:38:29 pm »
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

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 131
Re: File Stat Issue
« Reply #12 on: May 07, 2013, 03:31:55 am »
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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3941
  • Hero Points: 256
Re: File Stat Issue
« Reply #13 on: May 07, 2013, 09:18:22 am »
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

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 131
Re: File Stat Issue
« Reply #14 on: May 08, 2013, 12:33:18 am »
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?
« Last Edit: May 08, 2013, 12:35:06 am by chrisant »