Okay, further experimentation reveals some more data.
I created a file, attached an extended attribute to it with setfattr, then modified it in several different programs. Vi and Emacs, when they save, both destroy the extended attribute. (I didn't strace anything but vi, but I assume it's because of the same reason -- vi does actually delete the original file and recreate it.) The shell (when using >> redirection), Nano, Kwrite, and Kate all do not destroy the extended attributes. (Nano seem to do anything unusual. It does truncate the file and write it out again though. I didn't strace the others.)
...then it finally opens it with O_WRONLY and O_TRUNC (&O_CREAT), and that succeeds
Just in case it's not clear from that description, I'm pretty sure that's probably the same open call each time. Just in the first case, the O_CREAT flag comes into play because the preceding unlink succeeded and there is no file with that name, and in the second case, the O_TRUNC flag comes into play. In both cases, there's an empty file it writes into.
This is evil and anyone doing it should be KILLed on the spot, for the simple reason that removing and recreating a file destroys its permissions and requires the user to have write permission to the parent directory instead.
This is a good point. I was curious how things interacted with that, so I tried it. (The place where I got most of that information, which I linked to, is a Windows-centric source; if you go back to the DOS days, there were no permissions or whatnot to worry about. I knew that Unix programs also traditionally do something non-intuitive, so I assumed it was the same thing.)
I did an strace on vi as I saved a file. It does indeed appear to do what I said. It unlinks "temp.txt", renames it to "temp.txt~", then opens "temp.txt" again with O_CREAT (&O_TRUNC and OWR_ONLY). It does a few stats (of both files, at lots of times) and also a chmod of "temp.txt" -- presumably to fix that issue. I'm curious whether it would preserve extended attributes -- from this, I strongly suspect not -- but apparently the fairly old version of Knoppix I've booted doesn't have it enabled in the kernel (and my Linux installation is somewhat shot).
I chmod'd the directory so that I didn't have write access, and the behavior changed. The call to rename now returned EACCES (permission denied). It tried to open "testfile~" for writing, and that also returned EACCES. It tries a few other things (I don't exactly follow), but eventually it tries unlinking "testfile" again, which errors, so then it finally opens it with O_WRONLY and O_TRUNC (&O_CREAT), and that succeeds. It writes out the file's contents.
For one final test, I created a "testfile~" file before saving. In this case, it successfully opens testfile~ for writing and outputs the old old to it.
This argument has some merit, but at the same time, there are very good reasons why the current approach is a reasonable way to do things. The biggest is that it gives an appearance of something closer to a transaction. If your program goes through and overwrites data and dies halfway through, the file is probably going to be in a nonsense state.
However, say you write out the new information to a new file, delete the old file, and rename. If you die halfway through writing out the new file, the old file still lives. There are really only two inconsistent states that it could be in: the program dies before deleting the old file, in which case there is an extra file in the filesystem (which is possibly incomplete); and the program dies after deleting the old file but before renaming the new one to the old name, in which case the new file will be fully-written (let's ignore disk syncing), just have the wrong name.
While there are issues (see my earlier post in the thread for a discussion of how Windows does it, which I think is pretty reasonable), I think in all of these cases:
If you rename a file, does the "first created" time change? How about if you truncate it to zero length and write completely new information? What if you do both? The whole concept of "first created" is kind of murky unless files are only appended to....the answer is a pretty clear "the creation time stays the same". There are other, harder, questions, like what happens if you download a file, or email to someone? Should the creation time remain unchanged, or be when it arrived at your computer? What happens if you hand things across on a USB key?
If you want the time for the CONTENT, that obviously can't really be done by the file system. But oftentimes the existence of a particular file itself means something -- this is why truncation and refilling shouldn't affect the creation time.
The point isn't that it's as useful as mtime or ctime (though I will assert that done reasonably it'd be more useful than having both of those) or that it would be a fool-proof mechanism for determining the creation time of a file (or ever that such a notion has a universal definition), just that knowing some idea of a creation time would often be very useful (the OP's not the only person who's wished that Unix kept that information), and getting it right most of the time would be a lot better than saying "we can't do it completely right, so let's not do it it at all."
I know self-replies are stupid, but I should have mentioned something else. The metadata tunneling that Windows does is much more important than it is on Unix because the filename may need to be tunneled as well. If you open a file called "somefile with a long name.txt" in an old DOS program by opening SOMEFI~1.TXT (or even in a recent program) and it does this delete/create thing, you don't want the OS to say "oh, you're making a new file called SOMEFI~1.TXT. Spiffy"; you need the original "somefile with a long name.txt" name to carry over.
The linked site explains all this, but I know the propensity of/. readers (myself included) to RTFA.;-)
A lot of the time, modification of a file... isn't a modification of a file. Instead, the program will delete the existing file and create a new one in its place. (There is sometimes other operations in there, like saving to a temp file, deleting the original, then renaming the temp file to the original file name.)
This means that storing the real creation time of a file means that it won't be what you expect, because the file that you think is the same file actually isn't.
(MS-DOS/Windows have something called filesystem tunneling to attempt to get around this problem. If a file is deleted and a new one created in its place (see the MSDN article linked to from there for details) within a default 15 seconds, the creation time of the old file is carried over. This technique exchanges purity and absolute correctness (not that metadata times are reliable against tamper anyway) for utility.)
Well, add enough features and a filesystem begins to look like a source control system. I don't see any advantage by having file creation times tracked by the kernel -- better to do it in user space.
Um, you mean besides the fact that any program can make a file and that info will be available? Heck, why not put the ctime and mtime in userspace as well?
(Disclaimer: I wouldn't complain one bit if a filesystem behaved as a source control system. I already want versioning.)
In fact, I'm tremendously surprised that it doesn't do this already.
Can anyone who knows more about the kernel comment? *Does* it do them batched, and it's still a performance drain? If not, is there a reason that they aren't?
Being mugged is having money forcibly taken away and it's not losing money.
Um, what?
You could say the same thing about the death thing. "Being killed is having your money forcibly taken away, not losing your life by accident." There's a bit of a difference because there are things that you can do to reduce your chance of losing money, but that just reduces the kinds of deaths we can consider to ones where the person had a say. Such as being reckless, driving while not paying attention, deaths from smoking, some cases of cardiac arrest, etc.
I'm going to stay silent on the merits and demerits of the getting killed vs. accidental death thing, but you are being somewhat inconsistent.
I don't really know why ID are being blamed for this, since Valve is the distributor.
I would suspect ID packaged it, or at least provided the materials to be packaged, and along with it a statement that they had rights to distribute it. That seems much less likely than Valve removing the files.
What, should Valve now go and verify everything on Steam doesn't include GPL'd programs and not include the license, an impossible task in general?
In part, yes, but for some things, it doesn't go all the way.
For instance, Windows will give either the foreground application and/or programs the scheduler things are interactive a priority boost. (I forget exactly what it does.) In theory, this means that the program you're working with at the time gets the attention. It's conceptually like a window manager renicing the processes you're working with when you change focus.
I don't know if it actually makes a difference. It can also cause problems if a program can fool the scheduler into thinking it's interactive, because then it will get a bigger time slice than the priority says it should allow.
There *are* other ways to do scheduling besides just adjusting the nice level.
...before going on to start selling Linux distributions and releasing the entire code of the Windows kernel under the BSD license, you'd find some reasons to kick up a fuss about that, as well.
They'd probably go and release it under the old version of the BSD license, with the advertising clause, just to keep it GPL-incompatible and prevent mixing with the Linux base.
Did you read the post you're responding to? 140 inside the car
"In 2004, 35 children died of heat stroke in the US after being left unattended in a parked car. Previous research has shown that when ambient temperatures rise above 35C, sealed cars reach a suffocating 65C in just 15 minutes." http://www.newscientist.com/article.ns?id=dn7631
"According to a study funded by General Motors of Canada, Dr. Oded Bar-Or, a pediatrician and director of the Children's Exercise and Nutrition Centre at McMaster University, found that within 20 minutes the air temperature in a previously air-conditioned small car exposed to the sun on a 35C day (95 F) exceeded 50C (122 F). Within 40 minutes the temperature soared to 65.5C (150 F)." http://www.safety-council.org/quiz/sun_cars_and_ch ildrena.html
Where do you live that you can ignore traffic controls on your bike?
Then it's worse because a lot of the time the lights are timed for traveling at 30 mph instead of 15 mph, so you sit at a red light, it turns green, all the cars get through the next light, but just as you're approaching it turns red.
Waiting at stoplights isn't going to wear you battery down much.;-)
Besides, while TFA doesn't explicitly state this in the first couple paragraphs or what I skimmed, there's no way that this is running JUST on electricity. I don't think there's a person in the world who would spend $25K or whatever (number pulled out of ass) on a car that they can only go 8 miles. (Well, maybe Bill Gates.) It's a typical gas-electric hybrid, but where you can charge the battery externally then use it to go 8 miles. After your battery runs down, the gas will kick in as normal.
But for your short trips around town, you'll still use the gas engine much less, so it could still be worth it.
What if he lives in some place like Houston Texas, where during parts of the year you'll smell like a pig after standing around idle outside for 20 minutes? (Or at least I would, but I think I have northerly genes. I like temperatures in the 50s.) What if he lives in the rockies and it's up a mountain?
Congratulations on passing judgment before knowing the first thing about his situation.
Slashdot Mirror
Okay, further experimentation reveals some more data.
I created a file, attached an extended attribute to it with setfattr, then modified it in several different programs. Vi and Emacs, when they save, both destroy the extended attribute. (I didn't strace anything but vi, but I assume it's because of the same reason -- vi does actually delete the original file and recreate it.) The shell (when using >> redirection), Nano, Kwrite, and Kate all do not destroy the extended attributes. (Nano seem to do anything unusual. It does truncate the file and write it out again though. I didn't strace the others.)
On my list of the 10 best OSS projects, OpenBSD is in the top 5.
In other words... it's in your list of the 5 best OSS projects.
(sorry)
...then it finally opens it with O_WRONLY and O_TRUNC (&O_CREAT), and that succeeds
Just in case it's not clear from that description, I'm pretty sure that's probably the same open call each time. Just in the first case, the O_CREAT flag comes into play because the preceding unlink succeeded and there is no file with that name, and in the second case, the O_TRUNC flag comes into play. In both cases, there's an empty file it writes into.
This is evil and anyone doing it should be KILLed on the spot, for the simple reason that removing and recreating a file destroys its permissions and requires the user to have write permission to the parent directory instead.
This is a good point. I was curious how things interacted with that, so I tried it. (The place where I got most of that information, which I linked to, is a Windows-centric source; if you go back to the DOS days, there were no permissions or whatnot to worry about. I knew that Unix programs also traditionally do something non-intuitive, so I assumed it was the same thing.)
I did an strace on vi as I saved a file. It does indeed appear to do what I said. It unlinks "temp.txt", renames it to "temp.txt~", then opens "temp.txt" again with O_CREAT (&O_TRUNC and OWR_ONLY). It does a few stats (of both files, at lots of times) and also a chmod of "temp.txt" -- presumably to fix that issue. I'm curious whether it would preserve extended attributes -- from this, I strongly suspect not -- but apparently the fairly old version of Knoppix I've booted doesn't have it enabled in the kernel (and my Linux installation is somewhat shot).
I chmod'd the directory so that I didn't have write access, and the behavior changed. The call to rename now returned EACCES (permission denied). It tried to open "testfile~" for writing, and that also returned EACCES. It tries a few other things (I don't exactly follow), but eventually it tries unlinking "testfile" again, which errors, so then it finally opens it with O_WRONLY and O_TRUNC (&O_CREAT), and that succeeds. It writes out the file's contents.
For one final test, I created a "testfile~" file before saving. In this case, it successfully opens testfile~ for writing and outputs the old old to it.
This argument has some merit, but at the same time, there are very good reasons why the current approach is a reasonable way to do things. The biggest is that it gives an appearance of something closer to a transaction. If your program goes through and overwrites data and dies halfway through, the file is probably going to be in a nonsense state.
However, say you write out the new information to a new file, delete the old file, and rename. If you die halfway through writing out the new file, the old file still lives. There are really only two inconsistent states that it could be in: the program dies before deleting the old file, in which case there is an extra file in the filesystem (which is possibly incomplete); and the program dies after deleting the old file but before renaming the new one to the old name, in which case the new file will be fully-written (let's ignore disk syncing), just have the wrong name.
While there are issues (see my earlier post in the thread for a discussion of how Windows does it, which I think is pretty reasonable), I think in all of these cases:
...the answer is a pretty clear "the creation time stays the same". There are other, harder, questions, like what happens if you download a file, or email to someone? Should the creation time remain unchanged, or be when it arrived at your computer? What happens if you hand things across on a USB key?
If you rename a file, does the "first created" time change? How about if you truncate it to zero length and write completely new information? What if you do both? The whole concept of "first created" is kind of murky unless files are only appended to.
If you want the time for the CONTENT, that obviously can't really be done by the file system. But oftentimes the existence of a particular file itself means something -- this is why truncation and refilling shouldn't affect the creation time.
The point isn't that it's as useful as mtime or ctime (though I will assert that done reasonably it'd be more useful than having both of those) or that it would be a fool-proof mechanism for determining the creation time of a file (or ever that such a notion has a universal definition), just that knowing some idea of a creation time would often be very useful (the OP's not the only person who's wished that Unix kept that information), and getting it right most of the time would be a lot better than saying "we can't do it completely right, so let's not do it it at all."
That depends on what you're trying to do. Can you really not think of any uses for creation time?
I would much rather have creation time than both ctime and mtime.
I know self-replies are stupid, but I should have mentioned something else. The metadata tunneling that Windows does is much more important than it is on Unix because the filename may need to be tunneled as well. If you open a file called "somefile with a long name.txt" in an old DOS program by opening SOMEFI~1.TXT (or even in a recent program) and it does this delete/create thing, you don't want the OS to say "oh, you're making a new file called SOMEFI~1.TXT. Spiffy"; you need the original "somefile with a long name.txt" name to carry over.
/. readers (myself included) to RTFA. ;-)
The linked site explains all this, but I know the propensity of
There is a technical reason for this.
A lot of the time, modification of a file... isn't a modification of a file. Instead, the program will delete the existing file and create a new one in its place. (There is sometimes other operations in there, like saving to a temp file, deleting the original, then renaming the temp file to the original file name.)
This means that storing the real creation time of a file means that it won't be what you expect, because the file that you think is the same file actually isn't.
(MS-DOS/Windows have something called filesystem tunneling to attempt to get around this problem. If a file is deleted and a new one created in its place (see the MSDN article linked to from there for details) within a default 15 seconds, the creation time of the old file is carried over. This technique exchanges purity and absolute correctness (not that metadata times are reliable against tamper anyway) for utility.)
Well, add enough features and a filesystem begins to look like a source control system. I don't see any advantage by having file creation times tracked by the kernel -- better to do it in user space.
Um, you mean besides the fact that any program can make a file and that info will be available? Heck, why not put the ctime and mtime in userspace as well?
(Disclaimer: I wouldn't complain one bit if a filesystem behaved as a source control system. I already want versioning.)
That was my reaction too.
In fact, I'm tremendously surprised that it doesn't do this already.
Can anyone who knows more about the kernel comment? *Does* it do them batched, and it's still a performance drain? If not, is there a reason that they aren't?
Being mugged is having money forcibly taken away and it's not losing money.
Um, what?
You could say the same thing about the death thing. "Being killed is having your money forcibly taken away, not losing your life by accident." There's a bit of a difference because there are things that you can do to reduce your chance of losing money, but that just reduces the kinds of deaths we can consider to ones where the person had a say. Such as being reckless, driving while not paying attention, deaths from smoking, some cases of cardiac arrest, etc.
I'm going to stay silent on the merits and demerits of the getting killed vs. accidental death thing, but you are being somewhat inconsistent.
But, the nice thing is, that in space, you don't get heat convection, so the fire (theoretically) burns out quickly.
I don't really know why ID are being blamed for this, since Valve is the distributor.
I would suspect ID packaged it, or at least provided the materials to be packaged, and along with it a statement that they had rights to distribute it. That seems much less likely than Valve removing the files.
What, should Valve now go and verify everything on Steam doesn't include GPL'd programs and not include the license, an impossible task in general?
I call it rape.
Rape isn't rape if it's voluntary.
(Okay, there's statutory rape too, but are you under 18?)
And you really want to equate being forced to choose between not having cable or paying $56 a month with rape?
Isn't that what "nice" is for?
In part, yes, but for some things, it doesn't go all the way.
For instance, Windows will give either the foreground application and/or programs the scheduler things are interactive a priority boost. (I forget exactly what it does.) In theory, this means that the program you're working with at the time gets the attention. It's conceptually like a window manager renicing the processes you're working with when you change focus.
I don't know if it actually makes a difference. It can also cause problems if a program can fool the scheduler into thinking it's interactive, because then it will get a bigger time slice than the priority says it should allow.
There *are* other ways to do scheduling besides just adjusting the nice level.
They say "Jiggawatts" in the movie but it was really just a mispronunciation of gigawatts.
Or, depending on who you ask, a perfectly acceptable, if unusual, pronunciation of gigawatts.
They don't need to. I already pull faster rates from large MS downloads than almost anyone else.
And they would want to for the obvious reason.
...before going on to start selling Linux distributions and releasing the entire code of the Windows kernel under the BSD license, you'd find some reasons to kick up a fuss about that, as well.
They'd probably go and release it under the old version of the BSD license, with the advertising clause, just to keep it GPL-incompatible and prevent mixing with the Linux base.
Those bastards.
How do you feel about subsidizing Microsoft's bandwidth costs?
/. run on BT before? 47 thousand? And how many have had a comment like this? Zero?
Exactly how many articles has
...Windows wouldn't make use of the journaling feature, anyway.
Huh? What's that supposed to mean? Why wouldn't it?
Did you read the post you're responding to? 140 inside the car
h ildrena.html
"In 2004, 35 children died of heat stroke in the US after being left unattended in a parked car. Previous research has shown that when ambient temperatures rise above 35C, sealed cars reach a suffocating 65C in just 15 minutes."
http://www.newscientist.com/article.ns?id=dn7631
"According to a study funded by General Motors of Canada, Dr. Oded Bar-Or, a pediatrician and director of the Children's Exercise and Nutrition Centre at McMaster University, found that within 20 minutes the air temperature in a previously air-conditioned small car exposed to the sun on a 35C day (95 F) exceeded 50C (122 F). Within 40 minutes the temperature soared to 65.5C (150 F)."
http://www.safety-council.org/quiz/sun_cars_and_c
Where do you live that you can ignore traffic controls on your bike?
Then it's worse because a lot of the time the lights are timed for traveling at 30 mph instead of 15 mph, so you sit at a red light, it turns green, all the cars get through the next light, but just as you're approaching it turns red.
Waiting at stoplights isn't going to wear you battery down much. ;-)
Besides, while TFA doesn't explicitly state this in the first couple paragraphs or what I skimmed, there's no way that this is running JUST on electricity. I don't think there's a person in the world who would spend $25K or whatever (number pulled out of ass) on a car that they can only go 8 miles. (Well, maybe Bill Gates.) It's a typical gas-electric hybrid, but where you can charge the battery externally then use it to go 8 miles. After your battery runs down, the gas will kick in as normal.
But for your short trips around town, you'll still use the gas engine much less, so it could still be worth it.
What if he lives in some place like Houston Texas, where during parts of the year you'll smell like a pig after standing around idle outside for 20 minutes? (Or at least I would, but I think I have northerly genes. I like temperatures in the 50s.) What if he lives in the rockies and it's up a mountain?
Congratulations on passing judgment before knowing the first thing about his situation.