Because Windows filesystems lack any kind of usable symbolic or hard links,/../ on the end is interpreted as removing the last component of the filename. This works with open() and other calls, it is not a feature of this shell.
I agree it would be nice if Unix systems did this (or at least the shells did) if the plain filename did not match anything. It would eliminate the need to emulate the.. on non-unix filesystem implementations.
Windows internally can accept forward slashes in their filenames. I am hoping (though it may be futile) that Microsoft is going to allow, and maybe even encourage, them in this shell.
It is quite incredible that even on Slashdot people are brainwashed into thinking the filenames need to have backslashes.
I don't think you are addressing the parent's complaint.
Of course if you pull the disk, the disk may be trashed. The complaint is that there is no real reason this should trash the rest of the system, as well as the disk.
IMHO any reads/writes to a pulled disk should start returning errors at the moment the problem is detected (which may not be until it attempts to flush a block to the disk). The automount program could also get errors. I don't see why this is so hard to do. Most programs will gracefully handle this and print an error message and act as though the file was missing.
They're betting, of course, that the lost revenue from the handful of (what they think of as) fringe "rights nuts" like the people who post here is negligable because we're all pirates now anyway. But the amount of gained revenue by stopping technically ignorant pirates should more than make up for it.
This is where I think they are predicting very wrongly.
Currently the "rights nuts" (or more likely the "guys who like to brag how large their free music collection is") won't buy the CD, and will aquire it off the Internet. These same people will do anything necessary including building complex hardware to get around any copy protection and produce a digital file.
The "casual" pirate today will *buy* a CD and then give copies to their friends and put it on their MP3 player. What happens if they know that they will not be able to do this with the CD? Apparently the music industry believes they will tell their friends to buy their own copies of the CD, and they will purchase a new MP3/WMA player each year and pay to download a special copy of their music for it.
That is of course utter nonsense, what the person will do instead is search the internet, find the above "rights nuts" and get a *free* copy, and *not* buy the CD. The music companies have thus *removed* a potential sale!
The problem is that they are shooting themselves in the foot by trying to prevent "casual pirates". A "casual pirate" will buy a CD, just to rip it to an MP/3 file or to give it to their friends.
If they really believe this will force more CD's to be bought, they are idiots. If it is impossible to rip the CD to some other form, the desire to buy the CD goes *down*, not up. The "casual pirate", knowing that the CD is worthless for them, will spend their time searching the internet, to find the "professional pirate" who has the necessary sound-proof room and microphones to do a high-quality rip right off the digitally-encrypted speakers. They will not buy the CD any more!
He asked for examples of how a preinstalled Linux will have problems. In a preinstalled laptop, the wireless card will already be selected to be one that works in Linux and will already be configured.
This has nothing to do with making resolution-independent graphics.
Right now, I can draw a 1-inch square by querying the DPI and using that number to draw the square.
What I want is the *same* mechanism for drawing fonts. Using a totally different coordinate system for font sizes from all the other graphics is insane.
Unfortunatly due to the broken design and all the programs that are using it incorrectly, the only fix I can see is to make the existing API return 96 DPI always. There is no way to get all the existing X applications rewritten to stop using the point interface for selecting font sizes.
This does not mean it is not possible to add a new API that returns the real DPI. New programs can then use that to multiply the size of the font they want and then request that font size in points. Not only that, they can probably set the drawing transform so that everything is drawn in points. In fact what I want will greatly help resolution-independent graphics!
Unfortunatly X (and Windows, which has the same problem) was designed by morons. They thought it was extremely important that font sizes be resolution-independent, measured in "points", yet all other graphics are measured in pixels. The end result is that the display is fucked up if the DPI is set differently than what the programmers expect, since they are drawing everything with what are effectively two different coordinate systems, but it is almost impossible to correctly plan for arbitrary scale changes between them.
If anybody had any brains they would have measured the fonts in pixels. A program is perfectly capable of querying the DPI and multiplying the point size, if it really was interested in delivering a point size.
Windows, after many mess-ups and frustrated users with versions before 95, just forced the DPI to be 96 at all times, ignoring any information from the display driver or screen. (it also helped that the GDI32 font interface added a trivial modification to select fonts by pixel size (send a negative number for the point size) so programs could be fixed pretty easily).
I recommend that X do the exact same thing. The X server should act like DPI is 96 at all times. It would also help if the interfaces to select fonts by pixel size were not treated like second-class citizens.
Elektra is trying to put each configuration value into a sepearte file, named by the key, which is the correct way to use a file system. Unfortunatley both Unix/Linux and Windows have file systems designed to assumme that the average file is much larger than 1K, this is the real reason that this was not done and we have monstrosities like the registry, gconf, and the larger/etc files. The ReiserFS attempts to address this by being designed to support very small files efficiently.
Elektra is still screwed up, though. It is not XML, but the files have some structure to them, such as the ability to add comments. The files should be exactly the bytes of data of the value. Comments could be done by adding another file with another key, perhaps "keyname.comment".
I remember seeing that film on TV. Definately a Disney thing.
In that scene everybody was at desks with steering wheels, and watching a film on the screen in the front showing a view while driving, while the film narrator talked about what you were and should be doing. The instructions kept getting sillier, at one point you got stopped behind a bank getaway car, where the robbers jumped in with bags of loot and sped off, and the narrator said "did you remember to get the license plate number of the getaway car? Good."
I think then what happened is the film projector started speeding up and going real fast, then the film broke. Then it cut back to the kid and his desk was all wrecked from a crash.
Other responders seem to have missed the point of the parent poster.
What he is saying is that the attacks on the school are really weak and about minor-sounding annoyances. If the teacher's union is trying to slander the school with false accusations, he is claiming they would use much worse things than rules about wearing jackets, thus he is arguing they are not slandering it.
I have no idea or opinion on this case, but am annoyed at responders who do not even bother to comprehend what they are responding to!
They have cars in Europe, you know. They like them a lot, I seem to remember the Italians and Germans in particular really like cars. Doesn't stop them from having trains, too.
The fact that you *have* to "unmount" is the bug, you know.
I know, they may have trashed their data because they did not unmount. However it is silly to "punish" them by making it impossible to stick the disk back in to see if it is trashed.
Here is what I consider the ideal solution, far better than Windows or OS/X. Lets see if somebody can actually do this right:
When the drive is pulled, the system checks to see if all I/O had been flushed to it. If so it unmouts. The desktop environment responds instantly by removing any display of that drive or it's contents in file browsers.
If I/O has not been flushed the disk indicator remains in the desktop display, with a big red mark indicating that it had been pulled. Usually sticking it back in and pulling it after a second will flush the rest of the data and unmount it correctly. The user can also ignore it and stick new USB drives in (getting new icons) or do something on the menu to make it forget about the drive.
Attempting to shut down or log off with any red marked disks will ask the user to stick them back in so the data can be flushed. The user can hit cancel if they don't want to.
This flushing of a reinserted device must check carefully that it is the same device and it has not been written to by another machine while it was pulled.
All your options where the user can sign their own software could be done with no hardware support. The kernel could check these sums just as easy before running the program.
The idea of hardware to do encryption is nice, but this is the same industry that thought it was a good idea to save $3 by making the CPU do all the calculations formerly done by the modem chip (at a time when those calculations required 20% of the CPU power). So in no way are they adding this chip because it will speed things up.
The purpose of Trusted Computing is to introduce a public-key encryption where only the manufacturer knows the private key. There is literally a type of data that you *cannot* create, but the manufacturer can, and a simple test to see if a file is that type of data. The purpose is to make it impossible to write software for your own computer. Anything else is a smokescreen.
GPL and especially new BSD code is not "licensed". You don't sign anything. All they are are code that comes with at "you can violate the copyright if you do this" exception to US and international copyright laws. If copyright laws were repealed tomorrow the GPL would be meaningless because nobody at all agreed to any "license".
Seriously the idea of "free beer" is pretty obvious to anybody in an academic environment (like RMS and most of his intended audience). Beer is probably the easiest thing to get for free at a college. I suppose you can also get plastic cups equally easily. Sometimes there are chips and onion dip, but much less often than beer.
They may appear to work, but only for programs linked to the cygwin libraries. Open them with any other program and you get some cryptic garbage with the link target in it.
"Shortcuts" are NOT symlinks, in that a program has to understand them to use them. Symlinks in Unix are handled by the kernel and thus all programs (unless they specifically check if is a symlink) will get the original file.
In any case it sure sounds like they copied Unix "hard" links, which are actually a bad idea. They caused no end of difficulties in the early days when they could be arbitrary, though this was "fixed" by making it illegal to hard link to a directory so circles could not be created. As far as I can tell we would be quite well off with symlinks only. So it seems Microsoft has copied a defect of Unix and managed to not copy the symlinks we have been begging for for over a decade now!
(MS-sympathizier are sure to mention "junctions" again. Don't unless you will post CODE that compiles and works and can make a link from an arbitrary location on one disk to an arbitrary *FILENAME* on another disk by a user with no more priveledges than needed to create a file in the directory the link is in. The link must redirect the open() call from any C library that is capable of doing open() of a MSDOS disk file. If the disk is remote the link should work for everybody who can see it (though it might resolve to different locations). Your NFS server must correctly translate these to/from symlinks on NFS mounted disks (storing the drive letter in the target is ok). Targets missing a drive letter or leading slash should resolve as though the current directory is the directory the link is in.
I have a Mandrake box, and we bought a powerbook and got the free Epson printer that came with it. After messing with plugging/unplugging the usb cable from the printer to the powerbook many times, I said "I'll try plugging it into the Linux box. I know it won't work, everybody told me printing from Linux is a nightmare and not to attempt it, but just in case we won't have to keep pulling that plug.".
Well I plugged it in, and tried printing a page from Konqueror, and it worked!
I then went to the Powerbook, and after some fiddling, found the pulldown, selected the second printer, and it worked again! Output was identical to the output from directly connecting to the powerbook (including certain glitches which do not seem to be in the output from the Linux machine, which makes me think the Linux driver may be better).
It seems Slashdot is as big a source of FUD as anybody, as I seriously did not even attempt to plug the printer in, I was so convinced it would not work!
That said there were two problems: first I cannot seem to convince the Mac to forget about the fact that the printer was once directly plugged in, and they are named almost the same so there are two almost identical items on the pulldown. I guess I should search around on the Linux machine for some program to change the printer's name.
Second, and a more serious Linux-style problem, is that the printer abrubtly stopped working after I turned off the use of KDE for my own window manager and then rebooted the machine. It was obvious that lpq and so on were running, but the printer would not print and say it was "not responding" and the machine was aware if it was turned on/off, so it seemed I was not completely dead. I ran various configuration gui's and finally found something I think was called "lock down the usb port mapping" that fixed it.
Increasingly I am seeing things wrong with Linux where it is obvious the "hard" work has already been done, for instace USB devices can plug in and programs to print the status of USB instantly show the new device, the fact that it is a disk, the exact model and manufacturer, etc, and if I su and type enough stupid commands I can actually see the contents of the disk. Surely getting it to talk to the disk and read/write files from it is a lot harder than doing something so that the disk is automatically mounted, right? So why is this not being done, or designated as "part of the desktop environment"? I certainly want that disk mounted even if I am not running X! This is the exact type of frustration with Linux that leads to people complaining about it.
So should a directory full of files. This is a problem with both the API and with the command-line tools. There is no reason "cp dir1 dir2" should not work and make a new dir2 that contains all the same files as dir1. One reason I do not like attributes is that they discourage fixing the actual file system in ways like this.
* Some streams/attributes require special handling.
Same is true of files.
* Put complexity in the OS, not user code.
I have no idea what you are saying. I am quite certain that getting rid of attributes and having only files will make both the OS and user code simpler by a great deal.
* Implementation efficiency.
This is of course the actual reason this is not done. File systesm have always been designed to assumme a relativly small number of very large files. But recent file systems (ReiserFS) in fact address this issue.
On a NeXT machine. The NeXT desktop was dropping.desktop and other hidden files and directories all over the place and it had left some in root that I wanted to get rid of. Since they were directories and there was nothing else starting with dot, I typed "rm -R/.*". Stopped it after I noticed it was still churning after a minute, but by then the system was trashed.
You are missing the point. Why not store the data in files *UNDER* the file. IE every file is a directory. This is in fact what they are doing, but they went and invented a different syntax and require all-new API's to access the data, when files & directories are perfectly capable of it and should have been used. Same goes for Mac "resource forks". Read up on ReiserFS for a more correct implementation.
Slashdot Mirror
Because Windows filesystems lack any kind of usable symbolic or hard links, /../ on the end is interpreted as removing the last component of the filename. This works with open() and other calls, it is not a feature of this shell.
.. on non-unix filesystem implementations.
I agree it would be nice if Unix systems did this (or at least the shells did) if the plain filename did not match anything. It would eliminate the need to emulate the
Windows internally can accept forward slashes in their filenames. I am hoping (though it may be futile) that Microsoft is going to allow, and maybe even encourage, them in this shell.
It is quite incredible that even on Slashdot people are brainwashed into thinking the filenames need to have backslashes.
I don't think you are addressing the parent's complaint.
Of course if you pull the disk, the disk may be trashed. The complaint is that there is no real reason this should trash the rest of the system, as well as the disk.
IMHO any reads/writes to a pulled disk should start returning errors at the moment the problem is detected (which may not be until it attempts to flush a block to the disk). The automount program could also get errors. I don't see why this is so hard to do. Most programs will gracefully handle this and print an error message and act as though the file was missing.
They're betting, of course, that the lost revenue from the handful of (what they think of as) fringe "rights nuts" like the people who post here is negligable because we're all pirates now anyway. But the amount of gained revenue by stopping technically ignorant pirates should more than make up for it.
This is where I think they are predicting very wrongly.
Currently the "rights nuts" (or more likely the "guys who like to brag how large their free music collection is") won't buy the CD, and will aquire it off the Internet. These same people will do anything necessary including building complex hardware to get around any copy protection and produce a digital file.
The "casual" pirate today will *buy* a CD and then give copies to their friends and put it on their MP3 player. What happens if they know that they will not be able to do this with the CD? Apparently the music industry believes they will tell their friends to buy their own copies of the CD, and they will purchase a new MP3/WMA player each year and pay to download a special copy of their music for it.
That is of course utter nonsense, what the person will do instead is search the internet, find the above "rights nuts" and get a *free* copy, and *not* buy the CD. The music companies have thus *removed* a potential sale!
The problem is that they are shooting themselves in the foot by trying to prevent "casual pirates". A "casual pirate" will buy a CD, just to rip it to an MP/3 file or to give it to their friends.
If they really believe this will force more CD's to be bought, they are idiots. If it is impossible to rip the CD to some other form, the desire to buy the CD goes *down*, not up. The "casual pirate", knowing that the CD is worthless for them, will spend their time searching the internet, to find the "professional pirate" who has the necessary sound-proof room and microphones to do a high-quality rip right off the digitally-encrypted speakers. They will not buy the CD any more!
He asked for examples of how a preinstalled Linux will have problems. In a preinstalled laptop, the wireless card will already be selected to be one that works in Linux and will already be configured.
This has nothing to do with making resolution-independent graphics.
Right now, I can draw a 1-inch square by querying the DPI and using that number to draw the square.
What I want is the *same* mechanism for drawing fonts. Using a totally different coordinate system for font sizes from all the other graphics is insane.
Unfortunatly due to the broken design and all the programs that are using it incorrectly, the only fix I can see is to make the existing API return 96 DPI always. There is no way to get all the existing X applications rewritten to stop using the point interface for selecting font sizes.
This does not mean it is not possible to add a new API that returns the real DPI. New programs can then use that to multiply the size of the font they want and then request that font size in points. Not only that, they can probably set the drawing transform so that everything is drawn in points. In fact what I want will greatly help resolution-independent graphics!
Unfortunatly X (and Windows, which has the same problem) was designed by morons. They thought it was extremely important that font sizes be resolution-independent, measured in "points", yet all other graphics are measured in pixels. The end result is that the display is fucked up if the DPI is set differently than what the programmers expect, since they are drawing everything with what are effectively two different coordinate systems, but it is almost impossible to correctly plan for arbitrary scale changes between them.
If anybody had any brains they would have measured the fonts in pixels. A program is perfectly capable of querying the DPI and multiplying the point size, if it really was interested in delivering a point size.
Windows, after many mess-ups and frustrated users with versions before 95, just forced the DPI to be 96 at all times, ignoring any information from the display driver or screen. (it also helped that the GDI32 font interface added a trivial modification to select fonts by pixel size (send a negative number for the point size) so programs could be fixed pretty easily).
I recommend that X do the exact same thing. The X server should act like DPI is 96 at all times. It would also help if the interfaces to select fonts by pixel size were not treated like second-class citizens.
Elektra is trying to put each configuration value into a sepearte file, named by the key, which is the correct way to use a file system. Unfortunatley both Unix/Linux and Windows have file systems designed to assumme that the average file is much larger than 1K, this is the real reason that this was not done and we have monstrosities like the registry, gconf, and the larger /etc files. The ReiserFS attempts to address this by being designed to support very small files efficiently.
Elektra is still screwed up, though. It is not XML, but the files have some structure to them, such as the ability to add comments. The files should be exactly the bytes of data of the value. Comments could be done by adding another file with another key, perhaps "keyname.comment".
No.
I remember seeing that film on TV. Definately a Disney thing.
In that scene everybody was at desks with steering wheels, and watching a film on the screen in the front showing a view while driving, while the film narrator talked about what you were and should be doing. The instructions kept getting sillier, at one point you got stopped behind a bank getaway car, where the robbers jumped in with bags of loot and sped off, and the narrator said "did you remember to get the license plate number of the getaway car? Good."
I think then what happened is the film projector started speeding up and going real fast, then the film broke. Then it cut back to the kid and his desk was all wrecked from a crash.
Other responders seem to have missed the point of the parent poster.
What he is saying is that the attacks on the school are really weak and about minor-sounding annoyances. If the teacher's union is trying to slander the school with false accusations, he is claiming they would use much worse things than rules about wearing jackets, thus he is arguing they are not slandering it.
I have no idea or opinion on this case, but am annoyed at responders who do not even bother to comprehend what they are responding to!
Broken here, too: unknown host www.google.com
However just "google.com" does resolve (to 216.239.39.99 for me). But trying to load that seems to just redirect to www.google.com so it fails.
It's a sign of the apocalypse!
They have cars in Europe, you know. They like them a lot, I seem to remember the Italians and Germans in particular really like cars. Doesn't stop them from having trains, too.
No more donut wednesdays? No!!!!
The fact that you *have* to "unmount" is the bug, you know.
I know, they may have trashed their data because they did not unmount. However it is silly to "punish" them by making it impossible to stick the disk back in to see if it is trashed.
Here is what I consider the ideal solution, far better than Windows or OS/X. Lets see if somebody can actually do this right:
When the drive is pulled, the system checks to see if all I/O had been flushed to it. If so it unmouts. The desktop environment responds instantly by removing any display of that drive or it's contents in file browsers.
If I/O has not been flushed the disk indicator remains in the desktop display, with a big red mark indicating that it had been pulled. Usually sticking it back in and pulling it after a second will flush the rest of the data and unmount it correctly. The user can also ignore it and stick new USB drives in (getting new icons) or do something on the menu to make it forget about the drive.
Attempting to shut down or log off with any red marked disks will ask the user to stick them back in so the data can be flushed. The user can hit cancel if they don't want to.
This flushing of a reinserted device must check carefully that it is the same device and it has not been written to by another machine while it was pulled.
All your options where the user can sign their own software could be done with no hardware support. The kernel could check these sums just as easy before running the program.
The idea of hardware to do encryption is nice, but this is the same industry that thought it was a good idea to save $3 by making the CPU do all the calculations formerly done by the modem chip (at a time when those calculations required 20% of the CPU power). So in no way are they adding this chip because it will speed things up.
The purpose of Trusted Computing is to introduce a public-key encryption where only the manufacturer knows the private key. There is literally a type of data that you *cannot* create, but the manufacturer can, and a simple test to see if a file is that type of data. The purpose is to make it impossible to write software for your own computer. Anything else is a smokescreen.
GPL and especially new BSD code is not "licensed". You don't sign anything. All they are are code that comes with at "you can violate the copyright if you do this" exception to US and international copyright laws. If copyright laws were repealed tomorrow the GPL would be meaningless because nobody at all agreed to any "license".
Haven't been to college, huh?
Seriously the idea of "free beer" is pretty obvious to anybody in an academic environment (like RMS and most of his intended audience). Beer is probably the easiest thing to get for free at a college. I suppose you can also get plastic cups equally easily. Sometimes there are chips and onion dip, but much less often than beer.
They may appear to work, but only for programs linked to the cygwin libraries. Open them with any other program and you get some cryptic garbage with the link target in it.
"Shortcuts" are NOT symlinks, in that a program has to understand them to use them. Symlinks in Unix are handled by the kernel and thus all programs (unless they specifically check if is a symlink) will get the original file.
In any case it sure sounds like they copied Unix "hard" links, which are actually a bad idea. They caused no end of difficulties in the early days when they could be arbitrary, though this was "fixed" by making it illegal to hard link to a directory so circles could not be created. As far as I can tell we would be quite well off with symlinks only. So it seems Microsoft has copied a defect of Unix and managed to not copy the symlinks we have been begging for for over a decade now!
(MS-sympathizier are sure to mention "junctions" again. Don't unless you will post CODE that compiles and works and can make a link from an arbitrary location on one disk to an arbitrary *FILENAME* on another disk by a user with no more priveledges than needed to create a file in the directory the link is in. The link must redirect the open() call from any C library that is capable of doing open() of a MSDOS disk file. If the disk is remote the link should work for everybody who can see it (though it might resolve to different locations). Your NFS server must correctly translate these to/from symlinks on NFS mounted disks (storing the drive letter in the target is ok). Targets missing a drive letter or leading slash should resolve as though the current directory is the directory the link is in.
I have a Mandrake box, and we bought a powerbook and got the free Epson printer that came with it. After messing with plugging/unplugging the usb cable from the printer to the powerbook many times, I said "I'll try plugging it into the Linux box. I know it won't work, everybody told me printing from Linux is a nightmare and not to attempt it, but just in case we won't have to keep pulling that plug.".
Well I plugged it in, and tried printing a page from Konqueror, and it worked!
I then went to the Powerbook, and after some fiddling, found the pulldown, selected the second printer, and it worked again! Output was identical to the output from directly connecting to the powerbook (including certain glitches which do not seem to be in the output from the Linux machine, which makes me think the Linux driver may be better).
It seems Slashdot is as big a source of FUD as anybody, as I seriously did not even attempt to plug the printer in, I was so convinced it would not work!
That said there were two problems: first I cannot seem to convince the Mac to forget about the fact that the printer was once directly plugged in, and they are named almost the same so there are two almost identical items on the pulldown. I guess I should search around on the Linux machine for some program to change the printer's name.
Second, and a more serious Linux-style problem, is that the printer abrubtly stopped working after I turned off the use of KDE for my own window manager and then rebooted the machine. It was obvious that lpq and so on were running, but the printer would not print and say it was "not responding" and the machine was aware if it was turned on/off, so it seemed I was not completely dead. I ran various configuration gui's and finally found something I think was called "lock down the usb port mapping" that fixed it.
Increasingly I am seeing things wrong with Linux where it is obvious the "hard" work has already been done, for instace USB devices can plug in and programs to print the status of USB instantly show the new device, the fact that it is a disk, the exact model and manufacturer, etc, and if I su and type enough stupid commands I can actually see the contents of the disk. Surely getting it to talk to the disk and read/write files from it is a lot harder than doing something so that the disk is automatically mounted, right? So why is this not being done, or designated as "part of the desktop environment"? I certainly want that disk mounted even if I am not running X! This is the exact type of frustration with Linux that leads to people complaining about it.
* Files should be atomic objects.
So should a directory full of files. This is a problem with both the API and with the command-line tools. There is no reason "cp dir1 dir2" should not work and make a new dir2 that contains all the same files as dir1. One reason I do not like attributes is that they discourage fixing the actual file system in ways like this.
* Some streams/attributes require special handling.
Same is true of files.
* Put complexity in the OS, not user code.
I have no idea what you are saying. I am quite certain that getting rid of attributes and having only files will make both the OS and user code simpler by a great deal.
* Implementation efficiency.
This is of course the actual reason this is not done. File systesm have always been designed to assumme a relativly small number of very large files. But recent file systems (ReiserFS) in fact address this issue.
On a NeXT machine. The NeXT desktop was dropping .desktop and other hidden files and directories all over the place and it had left some in root that I wanted to get rid of. Since they were directories and there was nothing else starting with dot, I typed "rm -R /.*". Stopped it after I noticed it was still churning after a minute, but by then the system was trashed.
You are missing the point. Why not store the data in files *UNDER* the file. IE every file is a directory. This is in fact what they are doing, but they went and invented a different syntax and require all-new API's to access the data, when files & directories are perfectly capable of it and should have been used. Same goes for Mac "resource forks". Read up on ReiserFS for a more correct implementation.