Yeah there are, Linux supports parameters FALLOC_FL_INSERT_RANGE and FALLOC_FL_COLLAPSE_RANGE for fallocate(2). Like most fancy filesystem features, they are not used by the vast majority of software because it has to run on any filesystem so you'd always need to maintain two implementations (and extensive test cases).
Interesting that after decades of file system history, this is still considered a "fancy feature", considering that editing files is a pretty basic operation for a file system. Though I assume there are reasons why this hasn't become standard long ago.
File systems aren’t databases; they manage flat files, not structured data. You also can’t just insert/remove random amounts of bytes in RAM. The considerations here are actually quite similar, like fragmentation. If you make a hundred small edits to a file, you might end up with the file taking up ten times as much space due to fragmentation, and then you’d need the file system to do some sort of defragmentation pass to rewrite the file more contiguously again.
In addition, it’s generally nontrivial for a program to map changes to an in-memory object structure back to surgical edits of a flat file. It’s much easier to always just serialize the whole thing, or if the file format allows it, appending the serialized changes to the file.
File systems aren't databases, but journaling file systems use journals just like databases. It can theoretically define any granularity for something that might happen to a file to become an irreversible transaction. I suppose that file systems have to remain “general purpose enough” to be useful (otherwise they become part of the specific program or library), and that's why complex features which might become a pitfall for the regular users who expect “just regular files” rarely become the main focus.
But appending changes is a terrible solution, even if it is "much easier" to implement. Not only because it causes data leakage, as in this case, but also because it can strongly inflate the file size. E.g. if you change the header image of a PDF a few times.
Indeed, also userspace-level atomicity is important, so you probably want to save a backup in case power goes out at an unfortunate moment. And since you already need to have a backup, might as well go for a full rewrite + rename combo.
What this does on typical extent-based file systems is split the extent of the file at the given location (which means these operations can only be done with cluster granularity) and then insert a third extent. i.e. calling INSERT_RANGE once will give you a file with at least three extents (fragments). This, plus the mkfs-options-dependent alignment requirements, makes it really quite uninteresting for broad use in a similar fashion as O_DIRECT is uninteresting.
Well, better an uninteresting solution than a solution which is actively terrible: appending changes to a PDF, which will inflate its size and cause data leakage.
Bob wants a deb. I tell him to pound sand and give him a statically linked executable and pray that DNS works. If the software is still relevant in five years, some Debian maintainer will take an ancient version, convert it to use shared libraries, apply a dozen patches and give a .deb to Bob.
This word is doing a lot of lifting here. You are essentially saying "the world should be better" without even a hint of suggestion of what a minority of countries could do to achieve it (in the presence of adversarial, nuclear states)
Let's say someone is sick and they want to roll around in dog shit to cure themselves. I can say that's a bad idea and not be a doctor with a clinical diagnosis. That's a valid position.
Unilaterally bombing a country, overthrowing its government and installing a puppet leader to capture its oil reserves can be called a bad idea.
I don't need to have a fellowship at Georgetown or some sophisticated alternative.
Some things are obvious: stabbing your eye is a bad idea. no ophthalmology degree required.
Any medium or large C project has these kinds of project-specific (or sometimes company-specific) collections of log macros, error handling macros, etc. The amount of boilerplate here is minimal compared to that.
Fun fact: <details> even works on github and similar sites with markdown-based input. You can post large inline logs in issues without cluttering the conversation.
I used elinks once to find a solution to an issue where the login screen was broken after an upgrade. I was able to switch to a virtual console, find out about the issue, identify the commands to fix the issue, and use them to resolve the issue.
Yes, but it's fairly light-touch moderation. Newly registered first packages go through some automatic checks, and if they pass all those checks they are put on a 3-day waiting period for community to give feedback or raise objections to the package, and then at the end of the 3-day period, if nobody blocks it, the package is registered.
One of the automatic checks is a name similarity check, and if the name is too similar to an existing name, then the package is blocked from being auto-merged. At that point, someone will look at it, and there'll be a discussion on whether or not the name is okay. A lot of the time, the response is just "this is a false positive" and the package is greenlit. Other times, there's a discussion on whether or not the name is acceptable, and some alternative suggestions are given.
_______________
There was a little episode recently where someone tried to register a package with the same name as an existing package, but with two letters tacked onto the end of the name. Their package was just a fork of an existing package, but with a minor patch applied becuase they were frustrated that maintainers of the existing package weren't responding to pull requests.
The system automatically flagged the name, and the person was initially upset that they couldn't just register their fork, but within a couple hours we tracked down a maintainer to fix the existing package, and then we added this person as a maintainer to the original package so that they could review and accept pull requests to the package themselves. I think this ended up being a better solution for everyone involved.
reply