Earlier quoted context omitted.
It should also be said that `mv`(1) is only atomic if the source and destination are on the same filesystem.
So that implies that realistically there's a scenario where moving files or directories from one filesystem to another and some interruption occurs can lead to lost data?
Things Unix can do atomically (2010)
31–40 of 68 posts
Re: Things Unix can do atomically (2010)
#32In a few simple words, can someone explain what does "atomically" mean? I personally used this term when talking about some Redis operations, but never knew the real gist of the word and concepts behind it. I have a very brief understanding of the term and if I'd have to explain it to a person, I'd say it's "the operation that does not have any side effects when performing its unit of work". Is my understanding even…
Re: Things Unix can do atomically (2010)
#33Earlier quoted context omitted.
It should also be said that `mv`(1) is only atomic if the source and destination are on the same filesystem.
So that implies that realistically there's a scenario where moving files or directories from one filesystem to another and some interruption occurs can lead to lost data?
Re: Things Unix can do atomically (2010)
#34We had multiple systems that generated usage records, and stored them to flat file (think stuff that would end up on a bill). Because FTP the file was a thing, some other system would come in any copy the file, but every once in awhile there would be a partial file copied that would be missing records. Yep, it was the good ol process was still writing to the file when the collector decided to pick it up.
The first system I had control over, I made sure the vendor wrote to a temporary directory, and then hard linked to the transfer directory when the file operation was complete, knowing it avoided the race condition. I'm pretty sure I had one of the few platforms that handled this correctly, from what I remember we had corrupt files from almost all the platforms we bought.
Anyways, just because the system cost a million dollars doesn't mean it's any good.
Re: Things Unix can do atomically (2010)
#35The GCC Atomic Builtins mentioned in the article are not specific to Unix. They are compiler constructs, and depend on specific architecture hardware support. All x86 CPUs have such support for some years now. So these atomic operations can also be used in non-Unix software running on x86 CPUs. The GCC documentation lists other non-intel architectures which also have the features required to support the atomic built-…
Re: Things Unix can do atomically (2010)
#36In a few simple words, can someone explain what does "atomically" mean? I personally used this term when talking about some Redis operations, but never knew the real gist of the word and concepts behind it. I have a very brief understanding of the term and if I'd have to explain it to a person, I'd say it's "the operation that does not have any side effects when performing its unit of work". Is my understanding even…
If your code is too slow (a complex effect, too many character at that point), you might not be done writing a full frame when the graphic chips starts to output the pixels.
This means your TV is now showing partly old and new state. Nothing important most of the time, it's only games, it's only a few ms of absurd information, people's brain can compensate. It is ugly to see though. You have that weird 'line' somewhere below.
Since people changed the structure a bit, with two (or more) buffers, the program computes the new image in one buffer B, while the chip shows another buffer A. When you are done with a picture, the chip will now scan B, while you can write in A. This means the output never shows partial frame anymore.
Re: Things Unix can do atomically (2010)
#37Earlier quoted context omitted.
So that implies that realistically there's a scenario where moving files or directories from one filesystem to another and some interruption occurs can lead to lost data?
Very implausible. Mv across filesystems is usually implemented as a copy then delete. Worst case, you'll have the data exist in both locations.
Re: Things Unix can do atomically (2010)
#38In a few simple words, can someone explain what does "atomically" mean? I personally used this term when talking about some Redis operations, but never knew the real gist of the word and concepts behind it. I have a very brief understanding of the term and if I'd have to explain it to a person, I'd say it's "the operation that does not have any side effects when performing its unit of work". Is my understanding even…
Re: Things Unix can do atomically (2010)
#39Here's one that's not super well-known: writes to a pipe are atomic as long as the write size is Anyone know if there's a similar guarantee for files?
Re: Things Unix can do atomically (2010)
#40In a few simple words, can someone explain what does "atomically" mean? I personally used this term when talking about some Redis operations, but never knew the real gist of the word and concepts behind it. I have a very brief understanding of the term and if I'd have to explain it to a person, I'd say it's "the operation that does not have any side effects when performing its unit of work". Is my understanding even…