[Lateralus]

So... I've downloaded all 5 pieces of the Solaris 10 x86 DVD from Sun, and now I'm trying to combine them into the one ISO. The instructions state to;

"After downloading and unzipping segments, follow these instructions:
Reconstruct the full DVD image, by using the cat command (UNIX systems) or the COPY command (Windows systems).
The correct syntax is:
-cat file1 file2 file3 file4 file5 > file.iso or
-copy /b file1 + file2 + file3 + file4 + file5 file.iso"

So, under OS X, I go into Terminal and input the following command;

"cat /Users/ed/Desktop/Solaris/sol-10-u1-ga-x86-dvd-iso-e /Users/ed/Desktop/Solaris/sol-10-u1-ga-x86-dvd-iso-d /Users/ed/Desktop/Solaris/sol-10-u1-ga-x86-dvd-iso-b /Users/ed/Desktop/Solaris/sol-10-u1-ga-x86-dvd-iso-a /Users/ed/Desktop/Solaris/sol-10-u1-ga-x86-dvd-iso-c > solaris.iso"

Then, Terminal hums along, and according to Activity Monitor, cat uses about 15% of my CPU. This continues for a minute or two and then... nothing.

I'm not too big on software so I'm probably doing something wrong. Anybody know what it is?

Thank you.

[Caetano]

have you tried cd-ing into the folder first and then cat-ing?

[Tomchu]

Well, the process could have very well completed successfully -- it's just that the file is not where you expect it to be. If you've JUST opened the Terminal to do this, then the solaris.iso file will be in /Users/you (I'm assuming that would be /Users/ed).

[ghporter]

I'm with Caetano. It's always better to do this sort of command in the folder you're interested in; it saves typing errors AND reduces the OS's overhead for finding and manipulating the files in question. You could even go so far as to rename the ISO fragments with much shorter names like "iso-a" "iso-b" and so on.

It's possible ONE TINY typo can destroy the functionality of a "cat" command. Have you looked around for a result file? It's either going to be missing, empty, or of the wrong size, which could indicate what's going wrong. I think it's because "cat" wants to do its thing in the folder in question, and gets hung up on finding these files. Minimizing access time and location issues should make it clear what's going on.

[Tomchu]

Originally Posted by ghporter

It's always better to do this sort of command in the folder you're interested in; it ... reduces the OS's overhead for finding and manipulating the files in question.

Err ... what?

Trust me, it won't.

[ghporter]

Um...yes it will. Having to go through several layers of folders means more manipulation of the symbols for the files than using a short name in the current folder does. There's a condiserable amount of manipulation involved in using Terminal to multi-level folders, even if all the files are in the same, non-current folder. This is a basic rule of all operating systems: more indirection of files takes more work. AND it's simpler to type, proof, and verify, so the USER has less overhead too.

[Tomchu]

Originally Posted by ghporter

Um...yes it will. Having to go through several layers of folders means more manipulation of the symbols for the files than using a short name in the current folder does. There's a condiserable amount of manipulation involved in using Terminal to multi-level folders, even if all the files are in the same, non-current folder. This is a basic rule of all operating systems: more indirection of files takes more work. AND it's simpler to type, proof, and verify, so the USER has less overhead too.

The "Terminal" is really just Bash. When you refer to a file in the current directory, Bash just internally prepends $PWD to whatever file you just referenced before calling the appropriate application/OS function. As far as the OS/file system layer is concerned, you're referencing a file called ./whatever, which expands to /Users/Tom/whatever vs. referencing a file with /Users/Tom/whatever which -- get this -- doesn't expand to anything, because it's already expanded.

There is no difference between calling ./file1, ./file2, ./file3, compared to /usr/local/etc/file1, /Applications/file2, /Users/Tom/Desktop/file3. Everything gets expanded to a full path.

[ghporter]

Originally Posted by Tomchu

The "Terminal" is really just Bash. When you refer to a file in the current directory, Bash just internally prepends $PWD to whatever file you just referenced before calling the appropriate application/OS function. As far as the OS/file system layer is concerned, you're referencing a file called ./whatever, which expands to /Users/Tom/whatever vs. referencing a file with /Users/Tom/whatever which -- get this -- doesn't expand to anything, because it's already expanded.

There is no difference between calling ./file1, ./file2, ./file3, compared to /usr/local/etc/file1, /Applications/file2, /Users/Tom/Desktop/file3. Everything gets expanded to a full path.

Stating that this is trivial for the shell does not at all imply that the underlying OS functions are not more complex. A file in the current folder can be addressed by a very short file handle, and that can be manipulated in smaller registers and with faster CPU operations, while one that must be fully qualified requires a much longer (double or even quadword) file handle which must be manipulated in larger registers using slower operations. That's all I was refering to, not the level of abstraction "cat" works out to for the user. And with huge files, this extra manipulation of very long addresses in large registers can cause performance issues that the user can really see, while smaller files being manipulated would produce far less performance decreases which would be unnoticable.

EDIT: It was late for me when I typed it; I was thinking the wrong user name at the time... Sorry both!
Lateralus, have you made progress with this yet? Anything change your results?

[Tomchu]

I already mentioned this in my PM, but ...

Once the file is opened, and a file handle is generated, it does not vary in size depending on where in the directory hierarchy that file is, because the file handle itself does not keep track of directory layouts.

In C, a file handle is a pointer, so prove it to yourself by checking the data that the pointer points to for files opened in different directories.

[Lateralus]

Originally Posted by Tomchu

Well, the process could have very well completed successfully -- it's just that the file is not where you expect it to be. If you've JUST opened the Terminal to do this, then the solaris.iso file will be in /Users/you (I'm assuming that would be /Users/ed).

...you would be correct.

Thanks.

[ghporter]

Originally Posted by Tomchu

I already mentioned this in my PM, but ...

Once the file is opened, and a file handle is generated, it does not vary in size depending on where in the directory hierarchy that file is, because the file handle itself does not keep track of directory layouts.

In C, a file handle is a pointer, so prove it to yourself by checking the data that the pointer points to for files opened in different directories.

I wasn't talking about what happens AFTER the file is opened, only the process of finding it in the first place; arbitrary files outside the current directory require longer handles that need more work to manipulate than files within the current directory.

And you are aware that a pointer can be either "near" or "far," aren't you? A far pointer is longer and must be manipulated in longer registers than a near pointer. Manipulating a 32-bit register takes more cycles to set up and to perform than manipulating a 16-bit register, no matter what processor you're talking about.

[Tomchu]

Then if the overhead is really only during the opening of the file, there won't be any difference in throughput, will there? :-P Oh yippee, you save 100 clock cycles during fopen().

As for registers, I don't believe that there is any performance penalty for manipulating 32-bit registers vs. 16-bit registers, because the registers on x86/PPC are 32-bit, and can be read/written in one clock cycle -- that's the whole point of registers. If it takes >1 clock cycle to manipulate a CPU register, then you've done something very wrong with your CPU design.