#5405 closed bug (invalid)
Too many notifications after attribute change
Reported by: | laplace | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | File Systems/BFS | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
With node monitoring enabled, changing an attribute triggers a B_STAT_CHANGED notification after B_ATTR_CHANGED.
The B_STAT_CHANGED notification message contains in field "fields" B_STAT_SIZE and B_STATE_MODIFICATION_TIME). AFAICT the file size and modification time did not change.
This is an incompatibility to BeOS R5.
I had used B_STAT_CHANGED in an application as an easy indication that the contents of a file had changed. The application then tries to reload the file. However that application also updates some attributes after loading the file, which triggers now a B_STAT_CHANGED notification, which triggers a reload of the file, and so on...
Change History (5)
comment:1 by , 15 years ago
Description: | modified (diff) |
---|
comment:2 by , 15 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:3 by , 15 years ago
In hrev35534 I cannot reproduce B_STATE_SIZE and B_STATE_MODIFICATION_TIME in "fields" anymore when changing an attribute. Now there is B_STATE_CHANGE_TIME (0x80). Is this indented?
Tests were performed with both your test application and my application.
The command line tool addattr was used to add/change an attribute of the monitored file, like: addattr key value file
comment:5 by , 15 years ago
That is indeed intended, because that allows applications like rsync to see that it has to do something.
I wrote a small test application in hrev35526 in order to reproduce this problem. However, it works just fine.
Please add a test case that is able to reproduce the problem when reopening the ticket.