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 is wrong? I hate to tend to say something is wrong or not intuitive because there are more people coming from such DOS based products, any they have been trained to do things in a special way. 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 vipw, vigr, etc. Such wrappers copy the files to be edited to a separate file (may be after doing any kind of locking), then open the contents of the temporary file for editing. If you need such behavior, write your own shell wrapper (very easy), but don't force simple Unix tools to reopen every file and/or do create/write/rename sequences. >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). In addition the file descriptor may be used as the base for interprocess synchronization (called file locking). 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). 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. -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
