[BUG] vi does not recognize changed permissions on read only files

[Rich Felker]

On Thu, Oct 11, 2012 at 06:00:22AM +0200, Harald Becker wrote:
> Hi Rich !
> 
> >Of course this also has down-sides, such as losing extended attributes
> >and other file properties the application is not aware of, and not
> >being able to preserve ownership. That's why most programs by default
> >do what busybox vi is doing.
> 
> .... and not being able to write to special files, fifo's socket's etc.
> 
> They way you prefer to do things depends on how you learned such
> things ... and most people compare all things with those Mickysoft
> products and tend to say the way they learned there is the intuitive
> way ... but there are other ways too. So which one is right and which

Incidentally, the way you suggested vi should work is the Microsoft
idiom (keeping a file open while it's "open" in an editor and treating
open file handles as locks).

> IMO the usual Unix way is to work with file descriptors (not file
> names). That is not to reopen things ... or why there are things like

The way busybox vi works is the way EVERY traditional unix editor has
worked.

> >There is no precedent for this interpretation. Open file descriptions
> >are not locks.
> 
> Open file descriptors link to inodes. As this they file space is not
> freed even if any other process removes the directory entry (which is
> considered "the file" by so many Dos users).

This does not make it a lock.

> In addition the file
> descriptor may be used as the base for interprocess synchronization
> (called file locking).

Actually locks are on the underlying files, not the file descriptors.
You just need an open file descriptor to the file to place and hold
locks.

> Access to file data is not prohibited
> automatically, but space of file is marked in system for there is some
> work in progress. That is a kind of lock (preventing discarding space
> of old file).

No, it's a reference to a reference-counted resource. It has no
observable lock-like behavior.

> In addition there are network file systems which
> automatically deny writing to same file from different machines at the
> same time ... a lock, triggered by just opening the file and holding
> the file descriptor in an open state.

This is broken and nonconformant behavior.

Rich