Post #70,828
12/25/02 5:48:00 PM
|
HFS File basics
"Care is also known as "technical competence". Quite a few MacOS people tend not to esteem it very highly, I've noticed."
Apparently neither do so-called unix people who think they understand all *nix's because they understand one. Because you're not competent on this OS and you're giving out bad advice - which is really irresponsible. Because while I can tell its crap advice, others less competent might make the mistake of taking your fantasy posts as facts and suffer data loss.
"Resources on UFS are thus stored as dotfiles as adjuncts to the regular file (the former "data fork")"
Yes this is what the Finder does when its asked to move an HFS file to a UFS volume. Its in the paper I cited above. But the command line tools don't do this.
Allow me to introduce you to HFS+ where, if you have had a Mac for any period of time, most of your files are located.
Should you do the typical unix users thing - grab a terminal window and begin rearranging things with your favorite old tools, you stand a better than even chance of fucking up some of your important historical data (old Macintax or Quicken files for instance). Technical competence? Everything you think you know about the behvaior of mv, cp, and tar, is not quite right.
Let me also point out that should you desire to move them to UFS (which on OS X is actually not as cool of a file system in a lot of respects - lack of journaling for one, the fact that the rest of the OS is actually tuned for HFS+ another) you'll find that a lot interesting meta information about your file will be lost forever - like type and creator code. You'll find that the tar command on MacOS X that ships with the system does not properly add resource forks to files. Because on HFS+, they're not just files with name extensions.
So for the lurkers - this guy is giving out bad advice on a system he doesn't even use regularly. Ask someone else.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #70,875
12/26/02 1:00:34 AM
|
Envoi
You know, Todd or whoever/whatever you are, I simply have no interest in arguing with you. But in your spare time, you could try making a tarball of an entire directory (including dotfiles) on your (Mac OS 10-dot-whatever host's) UFS filesystem, and then untarring it into somewhere else on the same filesystem.
Gosh, what a surprise! All metadata are intact. I just ssh'd into my wife's iBook and [re-]tested that, and of course it (still) works fine. You'd almost think that understanding what your tools do, rather than indulging religious faith, is a reasonable strategy.
Whatever makes you happy, though; go crazy with it. But I believe we're now done. Time for you to go back to whatever it is that you do.
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
|
Post #70,890
12/26/02 3:04:16 AM
|
You could run the correct test
I don't use OS X, so I don't know what will or won't happen. But the fact is that you didn't test the scenario that Todd was complaining about.
Take files on an HFS filesystem. Tar them using standard unix tools. Untar them on a UFS filesystem. See if they are left intact.
Todd's claim is that they won't be, and the reason that Todd offers for why they won't be seems rather reasonable to me. Which suggests that you misunderstood what he was saying, and suggests that he actually does understand how the filesystems and associated filesystem tools work.
Cheers,
Ben
"Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly."
- [link|http://www.nationalinterest.org/issues/58/Mead.html|Walter Mead]
|
Post #70,896
12/26/02 3:54:27 AM
|
This would be my cue to ask this: (new thread)
Created as new thread #70895 titled [link|/forums/render/content/show?contentid=70895|This would be my cue to ask this:]
"Ah. One of the difficult questions."
|
Post #70,897
12/26/02 5:45:35 AM
|
Exactly - thanks
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #70,925
12/26/02 12:24:36 PM
|
I am understanding unix&tar has different capabilities?
Depending on the file system and on HFS it cannot traverse directories and files in the same fashion as UFS? If I have a NTFS directory using "crappy file name conventions.doc" when I tar it up it is fine but untarring it under unix would get several file not found messages?
thanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #70,962
12/26/02 4:40:42 PM
|
Not sure what you are asking
I don't know much about NTFS.
But I wouldn't try to tar up any classic style mac files and expect them to come out OK anywhere. Untarring on the mac is generally fine though.
You want to get a copy of hfstar for your OS X boxes. [link|http://www.metaobject.com|http://www.metaobject.com] has one (maybe look in community).
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #71,064
12/27/02 7:39:16 AM
|
No
I am saying that the behaviour that Todd is talking about is that standard Unix tools know nothing about turning metadata which is part of HFS into extra files that will be interpreted on other filesystems as that metadata. That is it turns one HFS file to one UFS file, which means that you lose all associated metadata that the HFS filesystem stores directly and UFS does not.
Cheers,
Ben
"Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly."
- [link|http://www.nationalinterest.org/issues/58/Mead.html|Walter Mead]
|
Post #71,073
12/27/02 10:32:17 AM
|
my point was Nix tools do not understand all file systems
so do not use where not applicable.
thanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #71,079
12/27/02 11:39:27 AM
|
You understand wrong
tar will create and extract archives in which filenames have embedded spaces. No problems. \r\n\r\n Where you may run into problems is with processing that uses " " as an inter-file seperator (man $( basename $SHELL) & search for IFS). Generally this situation is encountered in the form of a processing list, or with find / xargs process pipes: \r\n\r\n \r\n\r\nfor file in *\r\ndo\r\n echo "Now I'm going to do something with $file"\r\ndone\r\n \r\n \r\n\r\n ...tends to turn "My Documents" into "My" and "Documents". \r\n\r\n For find & xargs, the solution is to generate and expect null seperators: \r\n\r\n \r\n\r\nfind . -type f -print0 | xargs -0 foo\r\n \r\n \r\n\r\n I'm not quite sure where Todd's going with his explanation, but if Mac OS X is storing metadata in some form of file and .file, both extant in the same directory, tar should pick these up just fine. My understanding is that the filesystem is being used to store information in "special" files, but these files don't have other unusual characteristics other than their significance to the user shell. The trick is to use, say, "." (PWD) rather than "*" (glob of all files matching anything, so long as it's not a leading "."). But I freely admit a virtually complete lack of exposure to OS X. --\r\n
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]\r\n
[link|http://kmself.home.netcom.com/|http://kmself.home.netcom.com/]\r\n
What part of "gestalt" don't you understand?\r\n
[link|http://twiki.iwethey.org/twiki/bin/view/Main/|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n
\r\n
Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
|
Post #71,091
12/27/02 1:03:47 PM
|
well lets try it out
[105-112:~] boxley% mkdir foo
[105-112:~] boxley% cd foo
[105-112:~/foo] boxley% cat /dev/null > foo at bar
cat: at: No such file or directory
cat: bar: No such file or directory
[105-112:~/foo] boxley% ls
foo
[105-112:~/foo] boxley%
[105-112:~/foo] boxley% cat /dev/null >"foo at bar"
[105-112:~/foo] boxley% ls
foo foo at bar
[105-112:~/foo] boxley% ls -l
total 0
-rw-r--r-- 1 boxley staff 0 Dec 27 13:00 foo
-rw-r--r-- 1 boxley staff 0 Dec 27 13:02 foo at bar
when the nix os tries to untar the files with embedded spaces it cannot write the file to the disk because the OS does not recognise embedded spaces unless quoted which is a problem to untar unless you specifically know what file you need. That is why using a snmp notation in file names fooAtBar is a useful practice.
thanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #71,095
12/27/02 1:37:05 PM
|
You know dam well...
Box, You know dam well UNIX "sees" spaces as delimiters... you have to "backslash" them to take away the special meaning. You are really a Joker man... This issue has nothing to do with wether or not TAR can deal with embedded spaces... watch this... [gfolkert@paladin demo]$ cat /dev/null > foo bar\n[gfolkert@paladin demo]$ cat /dev/null > foo\\ at\\ bar\n[gfolkert@paladin demo]$ cat /dev/null > "foo not bar"\n[gfolkert@paladin demo]$ ls -l\ntotal 0\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo at bar\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo not bar\n[gfolkert@paladin test]$ You see the equivalence... now for tar[gfolkert@paladin demo]$ tar cvf demo.tar foo*\nfoo\nfoo at bar\nfoo not bar\n[gfolkert@paladin demo]$ ls -l\ntotal 12\n-rw-r--r-- 1 gfolkert users 10240 Dec 27 13:30 demo.tar\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo at bar\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo not bar\n[gfolkert@paladin demo]$ tar tvf demo.tar\n-rw-r--r-- gfolkert/users 0 2002-12-27 13:29:40 foo\n-rw-r--r-- gfolkert/users 0 2002-12-27 13:29:40 foo at bar\n-rw-r--r-- gfolkert/users 0 2002-12-27 13:29:40 foo not bar\n[gfolkert@paladin demo]$ mkdir test\n[gfolkert@paladin demo]$ cd test/\n[gfolkert@paladin test]$ tar -xvf ../demo.tar foo\\ at\\ bar\nfoo at bar\n[gfolkert@paladin test]$ ls -l\ntotal 0\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo at bar\n[gfolkert@paladin test]$ tar -xvf ../demo.tar "foo not bar"\nfoo not bar\n[gfolkert@paladin test]$ ls -l\ntotal 0\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo at bar\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo not bar\n[gfolkert@paladin test]$tar -xvf ../demo.tar foo bar\nfoo\ntar: bar: Not found in archive\ntar: Error exit delayed from previous errors\n[gfolkert@paladin test]$ ls -l\ntotal 0\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo at bar\n-rw-r--r-- 1 gfolkert users 0 Dec 27 13:29 foo not bar\n[gfolkert@paladin test]$ See that... THAT is what you are talking about not being supported. Bah...
[link|mailto:curley95@attbi.com|greg] - Grand-Master Artist in IT
[link|http://www.iwethey.org/ed_curry/|REMEMBER ED CURRY!]
[link|http://pascal.rockford.com:8888/SSK@kQMsmc74S0Tw3KHQiRQmDem0gAIPAgM/edcurry/1//|ED'S GHOST SPEAKS!] | Your friendly Geheime Staatspolizei reminds:
[link|http://www.wired.com/news/wireless/0,1382,56742,00.html| Wi-Fi Terrorism] comes with an all inclusive
free trip to the local Hoosegow! | | I'll never tell, my *overly-red* lips are sealed! *wink* *wink* |
|
Post #71,105
12/27/02 3:53:29 PM
|
point==missed
If you know the file name you can sort it out by calling for it in a manner the os will understand. If you are moving a huge subdir and you have a couple of badly named files in there they will not get moved over at the command line, you will have to parse it which is a little more tedious than tar this and untar this. That was the point I was trying to make.
thanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #71,107
12/27/02 4:03:58 PM
|
Windows, MAC OSX, MacOS9.x, *NIX
All have that same tendancy.
Try and move a file under windows that is named screwy... like "*A* Stoopid question\\answer/session? Me & Him .umx"
There isn't single OS barring VMS or OS400 that could address it easily.
[link|mailto:curley95@attbi.com|greg] - Grand-Master Artist in IT
[link|http://www.iwethey.org/ed_curry/|REMEMBER ED CURRY!]
[link|http://pascal.rockford.com:8888/SSK@kQMsmc74S0Tw3KHQiRQmDem0gAIPAgM/edcurry/1//|ED'S GHOST SPEAKS!] | Your friendly Geheime Staatspolizei reminds:
[link|http://www.wired.com/news/wireless/0,1382,56742,00.html| Wi-Fi Terrorism] comes with an all inclusive
free trip to the local Hoosegow! | | I'll never tell, my *overly-red* lips are sealed! *wink* *wink* |
|
Post #71,145
12/27/02 6:56:50 PM
|
ed zachery
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #71,148
12/27/02 7:46:43 PM
|
Windows has the bigger problem...
...in that those configuration parameters and file attributes and can't be copied by way of the standard utilities because they are in the Registry.
|
Post #71,146
12/27/02 7:05:36 PM
|
Wrong
You're confusing IFS with the OS's inherent ability to manipulate files with spaces. When working through the shell, these names need to be quoted. Tar handles 'em fine: \r\n\r\n \r\n\r\n[karsten@academy:karsten]$ cd tmp\r\n[karsten@academy:tmp]$ mkdir boxley\r\n[karsten@academy:tmp]$ cd boxley\r\n[karsten@academy:boxley]$ touch "a file with spaces"\r\n[karsten@academy:boxley]$ touch "another of the same"\r\n[karsten@academy:boxley]$ ls \r\na file with spaces another of the same\r\n[karsten@academy:boxley]$ cd ..\r\n[karsten@academy:tmp]$ tar czvf boxley.tar.gz boxley/\r\nboxley/\r\nboxley/a file with spaces\r\nboxley/another of the same\r\n[karsten@academy:tmp]$ mkdir untar\r\n[karsten@academy:tmp]$ cd untar \r\n[karsten@academy:untar]$ tar xzvf ../boxley.tar.gz \r\nboxley/\r\nboxley/a file with spaces\r\nboxley/another of the same\r\n[karsten@academy:untar]$ ll\r\ntotal 1\r\ndrwxr-sr-x 2 karsten karsten 128 Dec 27 18:02 boxley\r\n[karsten@academy:untar]$ ll boxley/\r\ntotal 0\r\n-rw-r--r-- 1 karsten karsten 0 Dec 27 18:02 a file with spaces\r\n-rw-r--r-- 1 karsten karsten 0 Dec 27 18:02 another of the same\r\n \r\n --\r\n
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]\r\n
[link|http://kmself.home.netcom.com/|http://kmself.home.netcom.com/]\r\n
What part of "gestalt" don't you understand?\r\n
[link|http://twiki.iwethey.org/twiki/bin/view/Main/|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n
\r\n
Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
|
Post #71,152
12/27/02 8:09:51 PM
|
The reason I brought this upo was recovering files from a
doze box to a linux box running rhat 7.0. Mounted a NT drive from the linux box and tarred about a gig onto the linux box tarball.tar. I ftp'd the file to a second linux box running 7.0 and untarred the file. On extraction it had problems with the type of file naming convention with spaces. I manually had to crawl thru the doze box directory by directory to get the files. That is why I brought it up. It appears to not be a problem as shown by your post.
hanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #71,167
12/27/02 10:15:59 PM
|
Two possible issues I can think of...
...barring your posting commands used. \r\n\r\n Some tars have an absolute cap on filename length. I'm not sure what this is with GNU tar, but recursing long names into a directory should identify whether this exists at any of the likely intervals (256, 512, 1024, 2048, 4096 characters, etc.). I have encountered this problem, possibly on either tar, CD ROM (the iso9660 format also has a total name length cap), or NTFS. \r\n\r\n Depending on how you were selecting files for inclusion in your tar archive, you may have run into the shell quoting issues mentioned earlier. You'll find that GNU tar does allow for null-terminated filenames, to work around the problem of embedded whitespace. Some folks feed find output to tar, in which case the problem can crop up. One of the reasons I prefer tar over such alternatives as cpio and afio is that tar will handle directory recursion itself while the other tools want input fed from stdin, by means that always require heavy manpage decoding by me. Note that there are some commendable advantages to the filestructures used by cpio & afio, I'm not criticising these. \r\n\r\n Bill, you made an absolute statement of what tar could or couldn't do. It's demonstrably wrong for GNU tar. If you care to show methods, we might be able to identify the source of the problem. It's not what you've represented it to be. --\r\n
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]\r\n
[link|http://kmself.home.netcom.com/|http://kmself.home.netcom.com/]\r\n
What part of "gestalt" don't you understand?\r\n
[link|http://twiki.iwethey.org/twiki/bin/view/Main/|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n
\r\n
Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
|
Post #71,180
12/27/02 10:43:35 PM
|
It was over a year ago so bear with me
had a NTFS box with a crossover cable connected to a linux laptop. The Drive was mounted via NFS to the /mnt mount point. Used SOSNT (son of sam nt a nfs server for nt) at the command line in bsh from the root directory used "tar cvf tarball.tar mnt" . after creating the file I disconnected the NT box and using the regular network ftp'd the tar file to a third linux box. Ran the command
"tar xvf tarball.tar" I noticed the ocassional error at that point "foo file name"
cannot extract file cannot extract name. So assumed it had a problem writing so went back to the source to get the files that wernt untarred manually. Now from your example it works just fine. I was using ext2 file systems on both linux boxes and RH 7.0 . Apparently what I saw belonged to another issue because as you have shown he it works just fine. Also works on darwin when I retested after your post. So I saw an abberation?
thanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #71,246
12/28/02 5:01:08 PM
12/28/02 5:02:03 PM
|
Once again, Todd's explanation
You are halfway to the problem. The problem is that sometimes MacOS uses special files, and sometimes not. tar does not understand this.
We have two filesystems. One of which (HFS) stores a file with lots of hooks for metadata. One of which (UFS) only directly supports the metadata that any Unix system has.
Going from HFS to UFS, what do you do with the important metadata? Apple decided to create new files for it. Therefore you cannot move a file from HFS to UFS without creating extra files.
The tar shipped with OS X doesn't understand this. And therefore does not create the needed extra files, and loses important metadata moving from HFS to UFS.
Personally (admittedly without much serious thought) what I would have been inclined to do in Apple's situation is have 2 sets of APIs for accessing files. One of which sees a traditional HFS file with metadata (on either system). The other of which sees the associated collection of files that are needed in UFS. Yes, there are problems with that as well. But then you would at least find it easy to get the appropriate consistent behaviour across filesystems.
BTW Linux may have a similar problem some day. (May already have in fact...) There is exploration of the idea of supporting streams within files in some filesystems. Copying a file with streams to a filesystem without streams has to be done...how? I haven't exactly been following discussion on this, but the following old post illustrates the issues that have to be thought through:
[link|http://web.gnu.walfield.org/mail-archive/linux-kernel/2000-August/1275.html|http://web.gnu.walfi...-August/1275.html]
Cheers,
Ben
"Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly."
- [link|http://www.nationalinterest.org/issues/58/Mead.html|Walter Mead]
Edited by ben_tilly
Dec. 28, 2002, 05:02:03 PM EST
|
Post #71,269
12/28/02 8:05:12 PM
|
Using a hammer to drive screws will hurt
Ben wrote:
The tar shipped with OS X doesn't understand this. And therefore does not create the needed extra files, and loses important metadata moving from HFS to UFS.
If you understand how files are stored, then you immediately realise why GNU tar is an inappropriate tool for such operations. A "problem" exists only if you're part of a funky computer religion that implicitly assumes you shouldn't have to understand the fundamentals of what you're doing.
BTW Linux may have a similar problem some day. (May already have in fact...)
That wouldn't be a "problem" any more than the ability to overwrite files with the "cat" utility is a "problem": Using an obviously unsuitable tool for a particular task, or otherwise aiming a gun at your foot and pulling the trigger, will inevitably have suboptimal results or worse.
So Don't Do That, Then.
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
|
Post #71,338
12/29/02 5:23:15 PM
|
I understand your position perfectly
You believe that all abstractions should be useless, and that nobody should be able to trust in anything without knowing the whole system perfectly.
There is a name for code produced by programmers who think like that. That name is spaghetti. And systems that are built like that inevitably become a [link|http://www.laputan.org/mud/mud.html|Big Ball of Mud].
Yes, I am part of a funky computer religion that implicitly assumes that you shouldn't have to understand the fundamentals of what you're doing - at least not all of the time. Abstractions like files and directories serve an important purpose, and the abstractions should not be broken lightly. And I am proud to say that that is a Good Thing.
Cheers,
Ben
"Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly."
- [link|http://www.nationalinterest.org/issues/58/Mead.html|Walter Mead]
|
Post #71,362
12/29/02 7:17:38 PM
|
Re: I understand your position perfectly
Ben wrote:
I understand your position perfectly. You believe that all abstractions should be useless, and that nobody should be able to trust in anything without knowing the whole system perfectly.
What an absolutely fabulous straw man you have there. May I take a whack at it, too, or do you have proprietary rights?
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
|
Post #71,572
12/30/02 6:16:31 PM
|
If it is not a straw man...
Then please explain how your position differs appreciably from what I described.
Regards,
Ben
"Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly."
- [link|http://www.nationalinterest.org/issues/58/Mead.html|Walter Mead]
|
Post #71,811
12/31/02 10:14:16 PM
|
Re: If it is not a straw man...
Ben wrote:
If it is not a straw man, then please explain how your position differs appreciably from what I described.
If I could figure out how you derived the extremely strange view you described immediately before attributing it to me, and then went on to draw even more peculiar conclusions from it, I'd gladly tell you which wrong turn you took on that road. But it's way too damn bizarre for my tastes, and it should suffice to say "No, I most certainly don't believe that, nor does anyone, actually."
I'm willing to believe that you honestly thought that. I guess. But I'm not going to try to prove to you that I don't hold a rather odd and silly view that strike me as nothing at all like what I said.
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
|
Post #71,962
1/2/03 4:55:17 AM
|
Funny, I concluded the same as Ben
YTF should I have to understand how the file system works to use it?
Do I also need to know the voltages in my ram chips to make proper use of memory in my software?
And of course, I mustn't write anything using sockets unless I clearly understand the inner workings of the entire communications stack and what is actually happening on the wires.
Better not drive a car without being able to calculate the thermal energy per unit of fuel - otherwise you'll probably run out someplace. You certainly can't trust that little needle - especially if you don't know how it works.
At some point, you have to use *abstractions* in order to move forwards or you will never transcend your current level of minutiae.
Your assertion that you must know the inner workings of the file system in order to use it is stupid.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #71,970
1/2/03 5:31:20 AM
|
Re: Funny, I concluded the same as Ben
ToddBlanchard wrote:
YTF should I have to understand how the file system works to use it?
Well, you needn't, of course. Just concentrate on watching the pretty pictures. Don't worry; be happy. Other people will take care of the technical stuff, and you can just wait for it to be delivered in idiotproofed form.
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
|
Post #72,164
1/3/03 4:27:19 AM
|
Little story - you might find it entertaining
I've been an avid skydiver since 1983. I've got over 24 hours of free fall time and over 1000 jumps (which means I've fallen something like 1500 miles).
When I started in the sport, before standardization of equipment, the number one cause of deaths wasn't "failed parachutes" (which was maybe 5% of problems - and today its less than a whole percent). It was "borrowed gear".
Every month I would eagerly rip open my new issue of Parachutist to read the accident reports - because its valuable (and safer) to learn from other people's mistakes.
In the early 80's skydiving was going through a transition period from outlaw practice to viable busineess. While lots of military surplus gear was still common, the first gear created strictly for pleasure jumping was beginning to appear on the market from a half dozen different companies.
The result was stuff shipped with a wide variety of "user interfaces" (handle placements). Some put the main deployment handle on a band crossing the belly. Other s on the left hip, or the right hip. The bottom of the pack was a common place while older gear had the main rip cord on the chest. Reserve ripcords were typically on the chest next to the cutaway handle for separating from the main parachute (if its trash you want it gone before opening old faithful) but left and right placement varied. Handle appearance varied as well. So you couldn't just grab a rig and know whats what. You had to ask the owner. I mean, if you don't know what it is, maybe you shouldn't jump it.
But people sometimes borrow gear because their stuff isn't packed when the plane is ready to go. So very knowledgeable skydivers would borrow something, get a quick explanation for what was where, (there's only 3 handles on a parachute, main, reserve, cutaway), and go make a jump.
And then they'd hit the ground pulling on the wrong thing. Lots of them. Gurus. Guys who had jumped everything under the sun and were as comfortable freefalling as lying in a hammock would bounce. The investigation would typically find that the guy was jumping something he had borrowed on the spur of the moment.
This cycle is repeating among the BASE jumping community as BASE gear evolves. You may remember the news story from a couple years ago of Jan Davis - one of the best and brightest - very publicly bouncing during a protest jump at Yosemite in 1999. The park officials were going to arrest the participants and confiscate their gear - so she borrowed something less nice than her regular rig. The unfamiliarity killed her (it wasn't lack of knowledge - she knew how it worked - she had hundreds of jumps on it).
The moral of this story is that variety kills. Today every single rig on the market has the handles laid out in exactly the same way and we don't have those kinds of accidents anymore. So for the same reason, I think its dangerous to mix file system types on a computer. At least until the tools evolve to properly handle the issues.
If the handles on the different file systems are different, accidents will happen.
Better knowledge is not the answer. Standardizing the interfaces is. All tools must become multi-file sytem aware or as Arkadiy says - we might as well keep sector maps on a pad of paper by our desk.
Of course, you seem to think you're bulletproof and your "knowledge" will protect you. It won't. You'll forget what file system you're on one day and slip. Like all those former skygods I used to know.
The dead ones.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #72,212
1/3/03 10:21:21 AM
|
Excellent story. Going on the wall.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #72,237
1/3/03 11:59:25 AM
|
This my dear friend... (new thread)
Created as new thread #72236 titled [link|/forums/render/content/show?contentid=72236|This my dear friend...]
[link|mailto:curley95@attbi.com|greg] - Grand-Master Artist in IT
[link|http://www.iwethey.org/ed_curry/|REMEMBER ED CURRY!]
[link|http://pascal.rockford.com:8888/SSK@kQMsmc74S0Tw3KHQiRQmDem0gAIPAgM/edcurry/1//|ED'S GHOST SPEAKS!] | The Heimatland Geheime Staatspolizei reminds:
[link|http://www.wired.com/news/wireless/0,1382,56742,00.html| Wi-Fi Terrorism] comes with an all inclusive
free trip to the local Hoosegow! | Please visit [link|http://z.iwethey.org/forums/render/board/show?boardid=1|iwethey.anti.anti++], providing
*THE* alternative to iwethey.anti-- since
June 18, 2001 22:00EST | | I'll never tell, my *overly-red* lips are sealed! *wink* *wink* |
|
Post #72,456
1/4/03 12:43:54 PM
|
Since you seem to be missing the point...
Here it is again.
Your attitude is that people should not use tools unless they know everything relevant to its proper usage. Your definition of what is relevant seems to be that if it might come up, then they need to know it. This is a circular definition of relevancy that justifies any particular dependency in hindsight as the user's fault for not knowing better.
Now I know that [link|http://www.joelonsoftware.com/articles/LeakyAbstractions.html|abstractions leak]. (That is one of the few articles by Joel that I agree with incidentally.) Furthermore I often find myself being in the position of being the person around who understands what abstractions leak, and why. There is no fundamental solution to that problem. Shit happens, and plumbers are needed for it.
However one mark of a programmer that you want to have around is the ability to see shit and recognize it for what it is. Leaking abstractions are signs of shit. While they may be inevitable, they are not something that you want to take lightly. Because a system built by people with too much tolerance for that inevitably degrades into a complete mess.
In this case the leaking abstraction is one of the worst kinds to have. Different filesystems use the same words for subtly different abstractions. This makes it hard for most people to even verbalize that there is a difference, let alone what it is. (When the same thing happens in speech you get classic threads where people talk past each other at length.) And when you try to combine them into one abstraction, the gaps keep on leaking past.
So yes, it happens for good reason. But it is a basic design flaw in the system. And it is not one to belittle people for getting tripped up by, nor is it one that has a simple right answer.
Cheers,
Ben
"Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly."
- [link|http://www.nationalinterest.org/issues/58/Mead.html|Walter Mead]
|
Post #74,798
1/16/03 4:13:56 AM
|
Re: Since you seem to be missing the point...
Ben Tilly wrote:
Your attitude is that people should not use tools unless they know everything relevant to its proper usage.
Not quite. Rather: I mildly (and not at all insistently, given that it's really not my problem) suggest that people should take responsibility for what they do. If you choose to use tools without adequately understanding them, you can pound your thumb with a misaimed hammer. The choice of taking that risk may be reasonable; the point is to not expect pity when you screw up and hurt yourself.
Personally, I prefer education over "learning experiences". Less painful.
Remainder of your post duly ignored as furious and tedious pummeling of an irrelevant straw man. Therapeutic though, I'm sure.
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
|
Post #71,434
12/30/02 5:21:30 AM
12/30/02 7:52:16 AM
|
I do not think that word means what you think it means.
"Using an obviously unsuitable tool for a particular task"
One day you will have to perhaps define your version of this word.
Firing up a terminal on OS X and navigating to an HFS file system, I find that I can:
ls
cat
mv
cp
chown
chgrp
chmod
ln
rm
Within an HFS volume and across HFS volumes just fine.
IOW, it appears that the developers of OS X have taken some pains to make sure that these tools work as expected on both UFS and HFS volumes. I fact, in the Fred Sanchez paper I cited awhile back, it describes the interesting strategies used to emulate hard links, soft links, file ownership, etc, that were taken to make the system behave as expected.
Its unfortunate that the illusion is incomplete (though I remain hopeful that this will be rectified with a future release).
But sometime you are going to have to share your definition of obvious with us.
Because what is clearly obvious to me is that what you claim to be obvious is not at all obvious to a daily user of the system.
It had been some months of daily command line development (I generally use vi and makefiles when I work - so is all in the shell) before I was bitten by the tar/cp/mv issue.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #71,440
12/30/02 8:21:08 AM
|
Hello, you must be going.
Hi there! I said we were done, and I meant that.
However, on your way back to whatever it is that you do, you might consider the merits of consulting manpages before just blithely assuming that someone has custom-modified a standard tool like GNU tar and GNU cpio/afio to perform operations they do nowhere else on the planet.
Or, if you prefer, you can ignore such considerations and bitch when reality bites you in the ass. Feel free to work out your options, somewhere.
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
|
Post #71,534
12/30/02 3:47:08 PM
|
This is obvious?
You wanna point out the obvious part?
Yeah, right. I don't see the letters UFS in there anywhere.
I don't see the letters HFS in there anywhere.
I imagine what you meant by "man" must have been the source code, eh?
>man tar
TAR(1) System General Commands Manual TAR(1)
NAME
tar - tape archiver
SYNOPSIS
tar [-]{crtux}[befhmopvwzHLPXZ014578] [archive] [blocksize] [-C directory
] [-s replstr ] file1 [file2...]
DESCRIPTION
The tar command creates, adds files to, or extracts files from an archive
file in tar format. A tar archive is often stored on a magnetic tape,
but can be a floppy or a regular disk file.
One of the following flags must be present:
-c Create new archive, or overwrite an existing archive,
adding the specified files to it.
-r Append the named new files to existing archive. Note that
this will only work on media on which an end-of-file mark
can be overwritten.
-t List contents of archive. If any files are named on the
command line, only those files will be listed.
-u Alias for -r
-x Extract files from archive. If any files are named on the
command line, only those files will be extracted from the
archive. If more than one copy of a file exists in the
archive, later copies will overwrite earlier copies during
extration.
In addition to the flags mentioned above, any of the following flags may
be used:
-b blocking factor
Set blocking factor to use for the archive, tar uses 512
byte blocks. The default is 20, the maximum is 126.
Archives with a blocking factor larger 63 violate the POSIX
standard and will not be portable to all systems.
-e Stop after first error.
-f archive Filename where the archive is stored. Defaults to
/dev/rst0
-h Follow symbolic links as if they were normal files or
directories.
-m Do not preserve modification time.
-O Write old-style (non-POSIX) archives.
-o Don't write directory information that the older (V7) style
tar is unable to decode. This implies the -O flag.
-p Preserve user id, group id, file mode, access and modifica-
tion times if possible. The user id and group id will only
be set if the user is the superuser (unless these values
correspond to the user's user and group ids).
-s replstr Modify the file or archive member names specified by the
pattern or file operands according to the substitution
expression replstr, using the syntax of the ed(1) utility
regular expressions. The format of these regular expres-
sions are:
/old/new/[gp]
As in ed(1), old is a basic regular expression and new can
contain an ampersand (&), \\n (where n is a digit) back-ref-
erences, or subexpression matching. The old string may
also contain <newline> characters. Any non-null character
can be used as a delimiter (/ is shown here). Multiple -s
expressions can be specified. The expressions are applied
in the order they are specified on the command line, termi-
nating with the first successful substitution. The
optional trailing g continues to apply the substitution
expression to the pathname substring which starts with the
first character following the end of the last successful
substitution. The first unsuccessful substitution stops the
operation of the g option. The optional trailing p will
cause the final result of a successful substitution to be
written to standard error in the following format:
<original pathname> >> <new pathname>
File or archive member names that substitute to the empty
string are not selected and will be skipped.
-v Verbose operation mode.
-w Interactively rename files. This option causes tar to
prompt the user for the filename to use when storing or
extracting files in an archive.
-z Compress archive using gzip.
-C directory This is a positional argument which sets the working direc-
tory for the following files. When extracting, files will
be extracted into the specified directory; when creating,
the specified files will be matched from the directory.
-H Follow symlinks given on command line only.
-L Follow all symlinks.
-P Do not strip leading slashes (``/'') from pathnames. The
default is to strip leading slashes.
-X Do not cross mount points in the file system.
-Z Compress archive using compress.
The options [-014578] can be used to select one of the compiled-in backup
devices, /dev/rstN.
FILES
/dev/rst0 The default archive name
SEE ALSO
pax(1), cpio(1)
AUTHOR
Keith Muller at the University of California, San Diego
ERRORS
tar will exit with one of the following values:
0 All files were processed successfully.
1 An error occured.
Whenever tar cannot create a file or a link when extracting an archive or
cannot find a file while writing an archive, or cannot preserve the user
ID, group ID, file mode or access and modification times when the -p
options is specified, a diagnostic message is written to standard error
and a non-zero exit value will be returned, but processing will continue.
In the case where tar cannot create a link to a file, tar will not create
a second copy of the file.
If the extraction of a file from an archive is prematurely terminated by
a signal or error, tar may have only partially extracted the file the
user wanted. Additionally, the file modes of extracted files and direc-
tories may have incorrect file bits, and the modification and access
times may be wrong.
If the creation of an archive is prematurely terminated by a signal or
error, tar may have only partially created the archive which may violate
the specific archive format specification.
BSD June 11, 1996 BSD
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #71,812
12/31/02 10:20:55 PM
|
Re: This is obvious?
ToddBlanchard wrote:
You wanna point out the obvious part?
It's the part where you understand the basics of how files are stored on your filesystems, understand how GNU tar / GNU cpio work, and avoid assuming (without confirmation) that those tools perform special functions, there, that they carry out nowhere else on the planet.
Khendon's Law duly invoked. Va t'en.
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
|
Post #71,868
1/1/03 3:14:02 PM
|
At no time did you utter the word "obvious" - nice dodge
thus you did not answer the question.
What is obvious to me is your lack of knowledge and use of bluster to compensate.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #71,891
1/1/03 5:34:29 PM
|
Re: At no time did you utter the word "obvious" - nice dodge
ToddBlanchard wrote, before reverting to argumentum ad hominem:
thus you did not answer the question.
Indeed, Chuckles. I was addressing the UFS/FFS topic at hand, which does not necessarily mean "answering your questions". You have perhaps confused me with some paid sidekick.
Now, run along.
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
|
Post #71,965
1/2/03 5:02:05 AM
|
Topic at hand - point out what you claim is "obvious" (new thread)
Created as new thread #71964 titled [link|/forums/render/content/show?contentid=71964|Topic at hand - point out what you claim is "obvious"]
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #70,950
12/26/02 4:10:28 PM
12/26/02 4:13:21 PM
|
Basic point seems to have been missed
Ben wrote:
Take files on an HFS filesystem. Tar them using standard unix tools.
That would be an obvious error, right there, and implies being clueless about how file storage works. The quoted suggestion is -- for anyone who understands how file storage works on MacOS X -- a bad idea regardless of whether you're going to untar them onto UFS or HFS+.
So, as the old joke goes, Don't Do That, Then. Part of the point of having most of your filesystem space be UFS is so that you can use standard Unix tools within the UFS majority storage (provided that you transport resources dotfiles with the related regular files). Saying that you can't reliably use such tools to move files onto HFS+ misses the point: You can't reliably use them within HFS+, either.
The Church of Steve solution is to use solely the worse filesystem, and deprive yourself completely of standard Unix filehandling tools, "because they're dangerous, and those recommending them are irresponsible".
"Fire bad, burn Lorto's finger, cause disharmony among tribe. No future in it. Stick to drawing icons on cave wall."
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.
Edited by rickmoen
Dec. 26, 2002, 04:13:21 PM EST
|
Post #70,956
12/26/02 4:33:37 PM
|
Yes you have missed it
every time. You can't seem to follow the thread. Ben exactly nailed it.
"Take files on an HFS filesystem. Tar them using standard unix tools."
Can you manage to follow those directions? Apparently not. I believe cp and mv has similar issues BTW.
You say:
"That would be an obvious error, right there, and implies being clueless about how file storage works."
That would be perhaps one of the more pompous and idiotic things you've ever said. Which is saying a lot.
What exactly is *obvious* about that error?
I have a commercial unix, with command line tools, that has a proprietary file system. For the most part the command line tools behave exactly as they do on any other unix. cat, mv, cp, ls, ln, all work like you would expect despite the underlying file system being HFS.
And I should obviously expect that with these tools all working as expected that the tar implementation that ships with that system would have issues with the files? Pray tell why? Clearly, the other tools have been modified to work on HFS.
It seems to me the very height of reasonable for a vendor shipping an OS with a set of file manipulation utilities would go to a bit of work to extend the utilities to work properly on their file system. The fact that they didn't is what I found really very surprising.
Fortunately, the community has answered and some extended utilities have been developed like the aforementioned hfstar, which works exactly like tar - because it is - only on hfs systems it converts the resource forks to the directory wrapper format you keep harping about on your wife's system.
Which is basically what I expected Apple would have shipped with the system and called "tar".
So shame on Apple for shipping lame assed tools like this.
But to imply that this is obvious is - well - really quite stupid.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #70,964
12/26/02 4:48:39 PM
|
I see so to use OSX effectively
blow away your 9.x partition with all those legacy apps and data. Reformat to UFS so unix tools will work. Sounds like a winblows solution to me.
Use the tool that does the job and have the wisdom to know the difference.
thanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
