Unix/Linux/OSX....can I link 2 folders to 1?

[westrock2000]

On my Mac I have a folder on my external drive linked (using the "ln" command) to the "Movies" folder in my User account. So I can click on the Movies folder and it goes straight to the external drive. I am starting to copy my DVD's over to this folder and 250Gb can only go so far. So my question, is can I make a link that directs the contents of two or more folders into one? Basically so when I go to Movies, it links /Volume/Lacie and /Volume/Lacie2 but it looks like one folder....I guess a RAID 0 without the RAID


I know Unix is much more versatile in how it handles "files", but I didn't know if this was possible.

 

[HHunt]

Not like that, no.
What you can do is a union mount. (Check the man page).
Basically, you mount the new drive on top of the old one. When you try to read a file from the combined directory, it checks the new drive first, then the old one if it's not there. When you create a file, it is placed on the new drive.

I can't offhand give you the right syntax for doing this in OS X, but I imagine something like "mount -t hfs+ -o union /dev/whatever /the/old/dir" would work. You'll have to look into the details, though.

 

[westrock2000]

Cool, thats a very interesting approach. I also figured that I could manually link each file to its respective harddrive. So it would basically do the same thing, just that I would have to do them individually

 

[GreNME]

What is this "more versatile" than? What a ridiculous statement.

But yeah, HHunt definitely gave the idea I was thinking of but couldn't name. Kudos, HHunt. If OS X doesn't have that exact mount, chances are a version of it can be found as source and compiled—just look for a PPC version of BSD and find the mount utility.

 

[HHunt]

What is this "more versatile" than? What a ridiculous statement.

Windows on NTFS is the common comparisation for linux and mac converts, so much so that it's implied unless anything else is said. As for "how", every *nix file system in use supports hardlinks, softlinks, and directory grafting, and all the common *nix OSes support at least one variant of union mounts. NTFS does directory grafting, and shortcuts sort of resemble softlinks.
I can't agree that it's ridiculous.

But yeah, HHunt definitely gave the idea I was thinking of but couldn't name. Kudos, HHunt. If OS X doesn't have that exact mount, chances are a version of it can be found as source and compiled—just look for a PPC version of BSD and find the mount utility.

Thanks.
I wouldn't actually recommend grafting tools from FreeBSD into OS X, the kernels are a bit different (and union is a feature of the kernel more than the mount tool). However, the Darwin man pages for mount (here) suggest that Darwin (and thus OS X) has a rather similar mount command (with union support).

 

[Fint]

you could do a whole crap load of symbolic links..

for i in `ls /your/first/folder/`; do ln -s $i /your/second/folder; done

 

[GreNME]

HHunt, NTFS can do the same things. However, the steps and what they are called is different. That is the only difference. I call it ridiculous because it is like trying to complain that an apple is not an orange, even if both fruit are ripe, succulent, and delicious.

I wouldn't actually recommend grafting tools from FreeBSD into OS X, the kernels are a bit different (and union is a feature of the kernel more than the mount tool). However, the Darwin man pages for mount (here) suggest that Darwin (and thus OS X) has a rather similar mount command (with union support).

I don't see why you wouldn't suggest it. I've grafted *nix tools onto my Windows install (GNUWin32) with absolutely no problems. OS X can handle it just fine, as long as it is compiled from PPC code and not overwriting already existant versions.

Still, since the current version seems to support it, the matter is moot anyway.

 

[Whatsisname]

What you are trying to do sounds like a bad idea altogether and you shouldn't do it unless you like to regularly misplace or completely lose your data.

 

[HHunt]

HHunt, NTFS can do the same things. However, the steps and what they are called is different. That is the only difference. I call it ridiculous because it is like trying to complain that an apple is not an orange, even if both fruit are ripe, succulent, and delicious.

I don't see why you wouldn't suggest it. I've grafted *nix tools onto my Windows install (GNUWin32) with absolutely no problems. OS X can handle it just fine, as long as it is compiled from PPC code and not overwriting already existant versions.

Still, since the current version seems to support it, the matter is moot anyway.

Ok, inform me on how you make the NTFS equivalent of a hardlink and a softlink, and I'll agree.

As for grafting *nix tools, ... no. Userland tools are fine, but you can't just compile something that depends on OS-specific kernel features and expect it to work. Note that the GNUWin32 tools are 1) ported (not just recompiled), and 2) almost entirely userland tools.

Also, the FreeBSD codebase is identical for all architectures, except for some few hardware-specific parts.
(The bootloader and a few parts of the kernel are assembler, some of the bus driver code is only relevant on one architecture, and there are a few differences between 64-bit and 32-bit architectures.)
There's only one source download, and it only contains one version of mount.c

 

[GreNME]

Ok, inform me on how you make the NTFS equivalent of a hardlink and a softlink, and I'll agree.

NTFS Hardlink

Now, unless you are satisfied with shortcuts, the only other way to symbolically link (that I know of) would include installing SFU or, as I have, the GNUWin packages. However, shortcuts really are the same thing (just take up more space), IMO.

Somehow, though, I bet you still won't agree.

As for grafting *nix tools, ... no. Userland tools are fine, but you can't just compile something that depends on OS-specific kernel features and expect it to work. Note that the GNUWin32 tools are 1) ported (not just recompiled), and 2) almost entirely userland tools.

Good idea to use "almost entirely" there, since there are things in there that make use of things that one would normally (incorrectly) assume are *nix-specific features. There are some caveats for some packages, requiring that certain DLL files be present (all freely available from Microsoft's site, and all present beforehand on XP). In the end, the only things you need to be concerned about are specific POSIX features, as XP/2k3 have had that subsystem removed (though it will be built into Vista). In such cases, you simply need to install SFU to get such features.

But I'm trying to avoid specific examples because there could be any number of them, depending on what you want/need/dream. If you've got a request, perhaps an option is already available. I have, over the years, worked out ways to get tasks interchangeable between *nix and NT, even if the exact same code base isn't used (because the kernels are obviously different). NT, *nix, and OS X all behave practically the same nowadays, so the capabilities are there for each. Finding them is sometimes obscure, though (libraries are also obviously different).

Also, the FreeBSD codebase is identical for all architectures, except for some few hardware-specific parts.
(The bootloader and a few parts of the kernel are assembler, some of the bus driver code is only relevant on one architecture, and there are a few differences between 64-bit and 32-bit architectures.)
There's only one source download, and it only contains one version of mount.c

That's cool, actually, because I wasn't sure of that.

 

[HHunt]

NTFS Hardlink

Now, unless you are satisfied with shortcuts, the only other way to symbolically link (that I know of) would include installing SFU or, as I have, the GNUWin packages. However, shortcuts really are the same thing (just take up more space), IMO.

Nice. Not their most publicised feature, but still.
I can't accept shortcuts as softlinks (because you'll get the shortcut file itself instead of the target a bit too often [1]), though they have the same basic idea.
If you use SFU to create softlinks, do they work with all programs, or just the POSIXish ones?

Somehow, though, I bet you still won't agree.

I wonder *cough* where you got that idea?

Good idea to use "almost entirely" there, since there are things in there that make use of things that one would normally (incorrectly) assume are *nix-specific features. There are some caveats for some packages, requiring that certain DLL files be present (all freely available from Microsoft's site, and all present beforehand on XP). In the end, the only things you need to be concerned about are specific POSIX features, as XP/2k3 have had that subsystem removed (though it will be built into Vista). In such cases, you simply need to install SFU to get such features.

I'm perfectly aware that you can do most *nix-ish things on windows, but that doesn't change my point that the kernel interfaces and features differ enough between OSes that simply recompiling core tools is far from a safe bet.
(Otherwise, I would have had mount_reiserfs on FreeBSD a long time ago.)

But I'm trying to avoid specific examples because there could be any number of them, depending on what you want/need/dream. If you've got a request, perhaps an option is already available. I have, over the years, worked out ways to get tasks interchangeable between *nix and NT, even if the exact same code base isn't used (because the kernels are obviously different). NT, *nix, and OS X all behave practically the same nowadays, so the capabilities are there for each. Finding them is sometimes obscure, though (libraries are also obviously different).

They can do the same things, yes. The details [2] differ a bit when you get closer to the kernel, which is why (as was my point) unchanged FreeBSD code that handles lowlevel file system work isn't likely to work unchanged on OS X, unless they didn't change anything when they imported it. This isn't very different from what you're saying, really.
Also, you'd have to find/create a mount_hfs for it to work. (If there is a native one it could use, it would have to support union mounts, and then what's the point?)

That's cool, actually, because I wasn't sure of that.

It's rather neat, yeah.
(NetBSD is better. You can crosscompile a complete system for any supported architecture with a few commands.)

[1] E.g. : If I "type ashortcut.lnk" I get the .lnk file. If I "cat somelink" I get the file it links to.
[2] What format for the device numbers? How do you specify the filesystem internally? Are the filesystem-specific parts kernel, userland, or some combination? (FreeBSD uses the userland programs mount_somefstype to mount a file system, but you still need kernel support. If I understand the comments correctly, they want to move away from using the mount_* tools to implement mounting. Doing so would require rewriting mount in a way that wouldn't even work on older versions of FreeBSD.)

 

[GreNME]

Nice. Not their most publicised feature, but still.
I can't accept shortcuts as softlinks (because you'll get the shortcut file itself instead of the target a bit too often [1]), though they have the same basic idea.
If you use SFU to create softlinks, do they work with all programs, or just the POSIXish ones?

Nope, works on all. Hell, if you just get a ported version of ln for Windows (like the GNUWin32 version or the SFU version), it does it just fine. Give it a try.

I wonder *cough* where you got that idea?

Call it a hunch.

I'm perfectly aware that you can do most *nix-ish things on windows, but that doesn't change my point that the kernel interfaces and features differ enough between OSes that simply recompiling core tools is far from a safe bet.
(Otherwise, I would have had mount_reiserfs on FreeBSD a long time ago.)

Woah there, tiger. I wasn't saying that recompiles would "just work" across all platforms. I said that a BSD recompile into OS X should work due to their similarities on the kernel level. It'd work a hell of a lot cleaner than a Linux->OSX recompile, IMO (which others I know have done).

They can do the same things, yes. The details [2] differ a bit when you get closer to the kernel, which is why (as was my point) unchanged FreeBSD code that handles lowlevel file system work isn't likely to work unchanged on OS X, unless they didn't change anything when they imported it. This isn't very different from what you're saying, really.
Also, you'd have to find/create a mount_hfs for it to work. (If there is a native one it could use, it would have to support union mounts, and then what's the point?)

Nope, the BSD one should work, as they are essentially the same thing. I can't imagine Apple changing something as straight-forward as that on the kernel just for the hell of changing it. The only reason I can think of for doing such a thing would be to make it a proprietary implementation, usually done on embedded OSes (like the version of Lynx used in Xerox copiers, for example), and even those have been minimal in my experience.

It's rather neat, yeah.
(NetBSD is better. You can crosscompile a complete system for any supported architecture with a few commands.)

Yeah, that just reminds me that I need to spend more time with those things. I've been playing the "make Linux and Windows play nice together" game for too long.

What format for the device numbers? How do you specify the filesystem internally? Are the filesystem-specific parts kernel, userland, or some combination? (FreeBSD uses the userland programs mount_somefstype to mount a file system, but you still need kernel support. If I understand the comments correctly, they want to move away from using the mount_* tools to implement mounting. Doing so would require rewriting mount in a way that wouldn't even work on older versions of FreeBSD.)

Unfortunately, I can't speak much for the proprietary system OSes (I don't work for them), but I believe that with Windows it is on the kernel level but working with a library (or libraries). This is why SFU enables so much more, as it simply adds to the abilities of the kernel that are already there. With OS X, I'm pretty sure that it is almost the same way BSD does it currently, which is why I made my original comment.

There isn't much you can't do in one OS that you can't do in the other, and when those instances pop up there are almost always ways to do something else that gets the same results. My favorite way of comparing is the difference between the registry hives (in Windows) and the many config files (in *nix).

 

[HHunt]

Nope, works on all. Hell, if you just get a ported version of ln for Windows (like the GNUWin32 version or the SFU version), it does it just fine. Give it a try.

Ok, that's neat. Why aren't shortcuts implemented like that?

Woah there, tiger. I wasn't saying that recompiles would "just work" across all platforms. I said that a BSD recompile into OS X should work due to their similarities on the kernel level. It'd work a hell of a lot cleaner than a Linux->OSX recompile, IMO (which others I know have done).

I'll agree that FreeBSD->OS X ought to be fairly clean, but that was what it looked like you were saying, and that was the essence of what I was saying.

Nope, the BSD one should work, as they are essentially the same thing. I can't imagine Apple changing something as straight-forward as that on the kernel just for the hell of changing it. The only reason I can think of for doing such a thing would be to make it a proprietary implementation, usually done on embedded OSes (like the version of Lynx used in Xerox copiers, for example), and even those have been minimal in my experience.

OS X is a strange, frankensteinian beast.
Also, the way mount.c works (I think), it looks for the filesystem-specific mount tool, and calls that with the right switches, unless it's not specified. Else, if the device exists, it tries UFS (hardcoded), otherwise is checks if it looks like an NFS path. I'm honestly not sure what happens if you just replace "UFS" with "HFS" in the right places, nor if it would work if you were actually mounting an UFS volume.

Yeah, that just reminds me that I need to spend more time with those things. I've been playing the "make Linux and Windows play nice together" game for too long.

Hehe. You know something is up when you consider recompiling unix systems a spare time you have to make room for.

Unfortunately, I can't speak much for the proprietary system OSes (I don't work for them), but I believe that with Windows it is on the kernel level but working with a library (or libraries). This is why SFU enables so much more, as it simply adds to the abilities of the kernel that are already there. With OS X, I'm pretty sure that it is almost the same way BSD does it currently, which is why I made my original comment.

Not entirely unlike how the different personalities of the FreeBSD kernel works, I guess. (The BSD personality is always enabled, but the Linux and OSF/1 personalities are on an equal footing.)
The reason I'm slightly sceptical is that I know there are small differences between e.g. NetBSD and FreeBSD, or older and newer 64-bit versions of FreeBSD (the time fields were changed to 64-bit some years ago). OS X has changed things both here and there, and the kernel is ... interesting. Taken together, I'd be suprised if all the relevant parts are have survived so unchanged that it would compile, much less work as intended. I doubt the changes are big, though.
I don't have access to an OS X box, and I don't really have the resources to install darwin right now, so I can't try. (I could take a look at the darwin code, come to think of it. Perhaps later.)

There isn't much you can't do in one OS that you can't do in the other, and when those instances pop up there are almost always ways to do something else that gets the same results. My favorite way of comparing is the difference between the registry hives (in Windows) and the many config files (in *nix).

I generally agree. They do however induce you to work in different ways and make different tools practical. (Versioning in VMS and shadow copy on 2003 server are closely related, but that doesn't mean you'd work the same way with them. )
How do you do a union mount in windows, anyway? That was where we started.

And since you're the most unixish windows guy I happen to know, let me throw out an unrelated, opinionated question. Do you think it's easier to get a dead unix up and running again than a windows? (Reinstalls don't count)

And btw, this forum needs to scale the number of allowed smileys with the number of lines of text. Mentally insert a few more where it fits.

 

[GreNME]

Ok, that's neat. Why aren't shortcuts implemented like that?

Heh, you're asking the wrong guy for that. In a (slightly more) perfect world, little stuff like ln would be implemented as closely as possible across the board for OSes. Just the unified troubleshooting for other software alone would make it worth the while to implement. The only thing I can posit is that Windows treats objects—including objects linking to other files—ever-so-slightly different than *nix. Think of it as almost an in-between of the file-based interface of *nix and the tool-based interface of OS X (and, even moreso, OS 9 and its predecessors). The Explorer shell is just an odd amalgam of the two (though I like it plenty).

I'll agree that FreeBSD->OS X ought to be fairly clean, but that was what it looked like you were saying, and that was the essence of what I was saying.

So... we're actually agreeing on the concept, just looking into the oddities between the ways other parts of OSes work similarly or the same?

OS X is a strange, frankensteinian beast.
Also, the way mount.c works (I think), it looks for the filesystem-specific mount tool, and calls that with the right switches, unless it's not specified. Else, if the device exists, it tries UFS (hardcoded), otherwise is checks if it looks like an NFS path. I'm honestly not sure what happens if you just replace "UFS" with "HFS" in the right places, nor if it would work if you were actually mounting an UFS volume.

I would say check the OS X version and see if that was what was done. I wouldn't be surprised if that was already done, and the only real difference being the kernel-level FS hooks are used to deal with HFS instead of UFS.

Hehe. You know something is up when you consider recompiling unix systems a spare time you have to make room for.

Hey, I have to learn this stuff somehow. However, I highly doubt I'll be compiling whole systems. I'm too lazy for that. Instead, I just try to find as many interchangeable parts or techniques as possible. It's helped me greatly with learning *nix and Windows, and with the exception of the Apple-specific stuff, OS X.

Not entirely unlike how the different personalities of the FreeBSD kernel works, I guess. (The BSD personality is always enabled, but the Linux and OSF/1 personalities are on an equal footing.)
The reason I'm slightly sceptical is that I know there are small differences between e.g. NetBSD and FreeBSD, or older and newer 64-bit versions of FreeBSD (the time fields were changed to 64-bit some years ago). OS X has changed things both here and there, and the kernel is ... interesting. Taken together, I'd be suprised if all the relevant parts are have survived so unchanged that it would compile, much less work as intended. I doubt the changes are big, though.
I don't have access to an OS X box, and I don't really have the resources to install darwin right now, so I can't try. (I could take a look at the darwin code, come to think of it. Perhaps later.)

Since I'm still trying to get my hands on a Mini for the purpose of dissection and study, I can totally sympathize.

I generally agree. They do however induce you to work in different ways and make different tools practical. (Versioning in VMS and shadow copy on 2003 server are closely related, but that doesn't mean you'd work the same way with them. )
How do you do a union mount in windows, anyway? That was where we started.

You know, I should have expected that to come up.

Since I have never even had an environment where a union mount would be warranted, I will be honest in saying I'm not sure of a single command or click-through to accomplish this. However, if you wanted to consolidate removable media files within Windows (like the OP), you could either treat it like a SAN (long and drawn out, but it could work) or—and this is what I would do—simply create symlinks (or, if feeling lazy, shortcuts) for the different media and let them be managed that way. I'd allow a simple batch file keep the links persistently accurate. For example:

               ------Folder1 -> e:\actualmediafolder1
Media---<
               ------Folder2 -> g:\actualmedafolder2

Obviously, not as elegant as a unified mount, but I have to admit I haven't put too much research for it. Can you offer me another situation that would warrant it outside of the OP's media folder situation? I try to follow the methodology of trying to the least problematic situation as possible, and since Windows mounts removeable media as their own drives instead of folders under the root, using the same method as with *nix would be more troublesome than it would be helpful. I do admit that it would be way more practical from a "techie" perspective, but I can't speak for the typical end user, who typically just prefers whichever method they got comfortable with first.

I'm more used to doing it in networked environments, at which point VDS for Windows 2003 can manage well enough and is seamless to the user on the other end. And, as per usual, it is just as simple to manage in a *nix environment.

And since you're the most unixish windows guy I happen to know, let me throw out an unrelated, opinionated question. Do you think it's easier to get a dead unix up and running again than a windows? (Reinstalls don't count)

Wow, the "most unixish windows guy," huh? That's gotta be one of the best tech-related compliments I have ever had said to me. I don't usually get a lot of compliments, but that was pretty cool...

The answer to the question is: both and neither. It always depends on the nature of the 'death' and the integrity of the file systems, the status of installed programs, which elements of the system have been damaged, and how deep the damage has gone. For both, if a repair job is going to take significantly longer than a reimage without really saving any mission-critical data anyway, then a reinstall it is. However, if there is critical data on the line, then see the the different possible contributors to the hosed system. If the damage goes down to the file system, the with both fsck and chkdsk I find myself usually very worried about possible results when trying to fix things. Both can be repaired from CD, both have locations where the components required to get it booted are editable (though with both, you have to know where as well as how), and both can have system files replaced to get it up and running (though with neither does it guarantee operational installed apps). I'd say it's pretty close to a wash, depending on your skill working with both.

Now, for me personally, I can fix Windows faster. However, I can fix a *nix as well, when necessary. I still need more of that learnin' stuff before I can claim equal skill for both.

And btw, this forum needs to scale the number of allowed smileys with the number of lines of text. Mentally insert a few more where it fits.

In my opinion, this forum needs more discussions along these lines instead of the "help me fix my broken system--support me!" threads. Not only are we able to share ideas, but I'm actually learning stuff and gaining just a little bit of help with some things I'm working on in my head for personal projects. This totally rocks.

 

[HHunt]

Heh, you're asking the wrong guy for that. In a (slightly more) perfect world, little stuff like ln would be implemented as closely as possible across the board for OSes. Just the unified troubleshooting for other software alone would make it worth the while to implement. The only thing I can posit is that Windows treats objects - including objects linking to other files - ever-so-slightly different than *nix. Think of it as almost an in-between of the file-based interface of *nix and the tool-based interface of OS X (and, even moreso, OS 9 and its predecessors). The Explorer shell is just an odd amalgam of the two (though I like it plenty).

I have a feeling that softlinks are a kernel feature, while shortcuts are merely an application-level optional component. The good thing about shortcuts (being able to embed information in them) should really have been done in a way that kept the kernel-level redirection for shortcut-unaware programs, IMHO. In a perfect world, indeed.

So... we're actually agreeing on the concept, just looking into the oddities between the ways other parts of OSes work similarly or the same?

Looks like it. There's a small but crucial difference between "easily portable" and "just recompile" that I thought you were glossing over in the first comment.

I would say check the OS X version and see if that was what was done. I wouldn't be surprised if that was already done, and the only real difference being the kernel-level FS hooks are used to deal with HFS instead of UFS.

Don't forget that it still handles UFS (and can boot from it, FWIW), so there's at least a small bit of added code somewhere. A place to start would be to see if it can mount UFS volumes without specifying the FS type. If not, they probably just moved UFS support out together with all other file systems, and replaced UFS with HFS as the default. (By far the simplest.)

Hey, I have to learn this stuff somehow. However, I highly doubt I'll be compiling whole systems. I'm too lazy for that. Instead, I just try to find as many interchangeable parts or techniques as possible. It's helped me greatly with learning *nix and Windows, and with the exception of the Apple-specific stuff, OS X.

Recompiling the system is sort of the way to do FreeBSD upgrades, but at least it's just a few simple commands. Not that you learn much from a source upgrade like that.

You know, I should have expected that to come up.

Since I have never even had an environment where a union mount would be warranted, I will be honest in saying I'm not sure of a single command or click-through to accomplish this. However, if you wanted to consolidate removable media files within Windows (like the OP), you could either treat it like a SAN (long and drawn out, but it could work) or -and this is what I would do- simply create symlinks (or, if feeling lazy, shortcuts) for the different media and let them be managed that way. I'd allow a simple batch file keep the links persistently accurate. For example:

               ------Folder1 -> e:\actualmediafolder1
Media---<
               ------Folder2 -> g:\actualmedafolder2

Obviously, not as elegant as a unified mount, but I have to admit I haven't put too much research for it. Can you offer me another situation that would warrant it outside of the OP's media folder situation? I try to follow the methodology of trying to the least problematic situation as possible, and since Windows mounts removeable media as their own drives instead of folders under the root, using the same method as with *nix would be more troublesome than it would be helpful. I do admit that it would be way more practical from a "techie" perspective, but I can't speak for the typical end user, who typically just prefers whichever method they got comfortable with first.

Thats more work than I put into it, actually. I store everything on a FreeBSD server, and just mount the drives as new drive letters (for samba) or mount points (for NFS) whenever I add a new one, then I try to split my files in a way that makes sense. So far it works fine, but it does lack some elegance. (I'll have to consider a software raid sometime.) I don't use external drives at all, and I don't see that changing in the future, at least not for any kind of permanent storage.

The only time I use union mounts would actually be when I boot LiveCDs (it's common to put a ramdrive on top of the directories mounted from the CD), and I hardly set that up myself. For me, it's not very important. Doesn't mean it can't be useful for someone (such as the OP, or liveCD hackers), and that's a good enough argument for me to put it in.

I'm more used to doing it in networked environments, at which point VDS for Windows 2003 can manage well enough and is seamless to the user on the other end. And, as per usual, it is just as simple to manage in a *nix environment.

Not knowing anything about VDS, I don't doubt it.

Wow, the "most unixish windows guy," huh? That's gotta be one of the best tech-related compliments I have ever had said to me. I don't usually get a lot of compliments, but that was pretty cool...

Hehe. You seem to fall into the small camp of people who run windows yet actually know the alternatives. (This does say some rather negative things about most of the windows-people I've met, but don't let that distract you.)

The answer to the question is: both and neither. It always depends on the nature of the 'death' and the integrity of the file systems, the status of installed programs, which elements of the system have been damaged, and how deep the damage has gone. For both, if a repair job is going to take significantly longer than a reimage without really saving any mission-critical data anyway, then a reinstall it is. However, if there is critical data on the line, then see the the different possible contributors to the hosed system. If the damage goes down to the file system, the with both fsck and chkdsk I find myself usually very worried about possible results when trying to fix things. Both can be repaired from CD, both have locations where the components required to get it booted are editable (though with both, you have to know where as well as how), and both can have system files replaced to get it up and running (though with neither does it guarantee operational installed apps). I'd say it's pretty close to a wash, depending on your skill working with both.

Now, for me personally, I can fix Windows faster. However, I can fix a *nix as well, when necessary. I still need more of that learnin' stuff before I can claim equal skill for both.

<minirant>
I have this feeling I run into a wall whenever windows doesn't boot. The repair console is fine for a few, specific problems (not the ones I run into) and besides, it's not always available (ISTR that you can install it, but by the time something I didn't install dies, it's too late to think about that), repair installations from the CD do work now and then [1] but are sort of brutal. Filesystem damage is seldom the problem.

A good and irritating example (that happens to me now and then) is when windows loses track of where it lives. There's nothing like the sinking feeling of "ntoskernel not found" after changing a few partitions, because I know there's no way to fix it that doesn't require me to poke into the file system from the outside. [2] (Reminds me, I have to borrow a 2003 server CD at school tomorrow.)

What bothers me the most is that at no time during the windows boot do you really feel in control. You get a few boxed alternatives that have a chance of working (or in the above case, not) , but it's so ... weak. It depends on far too many things working, [3] and is thus much too easy to render useless.
(If it doesn't come up in safe mode, it's a brick. Reinstall.)
</minirant>
Ah, that felt good. Biased, factually suspect, unrelated to anything, but that's par for the course.

In my opinion, this forum needs more discussions along these lines instead of the "help me fix my broken system--support me!" threads. Not only are we able to share ideas, but I'm actually learning stuff and gaining just a little bit of help with some things I'm working on in my head for personal projects. This totally rocks.

It's a welcome change, for sure.
(But I think we scared away the others.)


[1] But what determines if the option shows up? My experience has been rather hit/miss, mostly the latter.
[2] Just to show where I come from: If FreeBSD can't find the kernel, it asks what device it should mount as / .You even get a list of alternatives. After that, it should boot fairly normally, and it's just a case remembering to change the relevant fstab line to avoid it happening again.
And do feel free to prove me wrong by showing me a simple way to fix this from the repair console.
[3] As long as the kernel starts, the root FS is mounted succesfully and I get a tty, I can fix things in a *BSD. I can skip the graphics. I can skip almost all the drivers or load alternates. (I could load a kernel from a CD and a few modules of a floppy if the situation required it). I can skip the init scripts. At worst it's so primitive a SysV-hacker would feel at home, but that is infinitely preferable to a system that doesn't boot at all. I don't think I've ever gotten a FreeBSD installation into a state that couldn't be fixed with only the tools it gives you.
(Doing make installworld with a broken world build would probably do it, since there's no easy way to recover from most/all tools not working. Also, I'll have to count the install CD as "the tools it gives you" when it comes to overwritten bootloaders.)

 

[GreNME]

I have a feeling that softlinks are a kernel feature, while shortcuts are merely an application-level optional component. The good thing about shortcuts (being able to embed information in them) should really have been done in a way that kept the kernel-level redirection for shortcut-unaware programs, IMHO. In a perfect world, indeed.

Well, shortcuts allow extra arguments to be passed as well while still being in userspace. Obviously, there are alternatives with other operating systems, but the way shortcuts were originally designed were with an OS that was not capable of the things NT is. I chalk them up to a vestigal tail of the old versions of Windows. Not really harmful or helpful, but it's not like we really need them anyway.

Looks like it. There's a small but crucial difference between "easily portable" and "just recompile" that I thought you were glossing over in the first comment.

Yeah, I was kinda terse with my statement, and I should be more careful with that when dealing with users who do not regularly swap between different environments.

Don't forget that it still handles UFS (and can boot from it, FWIW), so there's at least a small bit of added code somewhere. A place to start would be to see if it can mount UFS volumes without specifying the FS type. If not, they probably just moved UFS support out together with all other file systems, and replaced UFS with HFS as the default. (By far the simplest.)

See, and this is making me wish I had an OS X box here now.

Recompiling the system is sort of the way to do FreeBSD upgrades, but at least it's just a few simple commands. Not that you learn much from a source upgrade like that.

Oh, I've recompiled when adding drivers to perform specific tasks (usually Linux and having something to do with the network drivers, like with the Orinoco passive switch). I just try to avoid it when I can because while I can look at code and, given enough time, understand it well enough, I am simply not a programmer. In fact, I totally admit to being a sloppy and dirty programmer (slimming and cleaning the code once I figure it out and am applying it to work).

Thats more work than I put into it, actually. I store everything on a FreeBSD server, and just mount the drives as new drive letters (for samba) or mount points (for NFS) whenever I add a new one, then I try to split my files in a way that makes sense. So far it works fine, but it does lack some elegance. (I'll have to consider a software raid sometime.) I don't use external drives at all, and I don't see that changing in the future, at least not for any kind of permanent storage.

I'm much the same. I have drives in my server (running SBS) that are sharing the stuff I want, which is mounted at will by whichever OS I choose and the biggest obstacle for me is keeping all those files consolidated (hence sharing in the first place, to avoid sixteen copies of my regularly-used documents).

The only time I use union mounts would actually be when I boot LiveCDs (it's common to put a ramdrive on top of the directories mounted from the CD), and I hardly set that up myself. For me, it's not very important. Doesn't mean it can't be useful for someone (such as the OP, or liveCD hackers), and that's a good enough argument for me to put it in.

Yeah, I would mostly suggest that when working with Windows a different method than attempting a union mount for the OP-like situation, since there are other elements in place to allow quick and easy access (not to mention archiving content inside of media players, and so on). There are similar things at play in OS X, but the fact that the file system is still, at its core, still *nix-based.

Not knowing anything about VDS, I don't doubt it.

It's cool stuff. Just another of those "it's about time" things with the newer Windows OSes. Like a breath of fresh air for sysadmins everywhere.

Hehe. You seem to fall into the small camp of people who run windows yet actually know the alternatives. (This does say some rather negative things about most of the windows-people I've met, but don't let that distract you.)

Doesn't distract me at all. I've used Windows since 3.1, but I didn't start getting into the techie aspects until later and had the opportunity to start learning little bits of other OSes at the same time. Unfortunately, it lumps me into a "Jack of all, master of none" situation in general, though my strengths lie mainly with Windows because it's been the most accessible to me when learning through experience. I actually like multiple systems, so it's all zen with me.

<minirant>
I have this feeling I run into a wall whenever windows doesn't boot. The repair console is fine for a few, specific problems (not the ones I run into) and besides, it's not always available (ISTR that you can install it, but by the time something I didn't install dies, it's too late to think about that), repair installations from the CD do work now and then [1] but are sort of brutal. Filesystem damage is seldom the problem.

I have that "hitting a wall" feeling with *nix a lot. I've been lucky that people have been able to show me how to get a lot of things working, because my biggest gripe is the lack of an accessible resource like the MSKB for whichever distro I am using at the time. Man pages often read to me like a programmer talking to another programmer, which tends to make my mind become less receptive until I "get it."

A good and irritating example (that happens to me now and then) is when windows loses track of where it lives. There's nothing like the sinking feeling of "ntoskernel not found" after changing a few partitions, because I know there's no way to fix it that doesn't require me to poke into the file system from the outside. [2] (Reminds me, I have to borrow a 2003 server CD at school tomorrow.)

Hrm... ever think of trying a LiveCD? I tend to install the Recovery Console as a matter of course when first installing the OS.

What bothers me the most is that at no time during the windows boot do you really feel in control. You get a few boxed alternatives that have a chance of working (or in the above case, not) , but it's so ... weak. It depends on far too many things working, [3] and is thus much too easy to render useless.
(If it doesn't come up in safe mode, it's a brick. Reinstall.)
</minirant>
Ah, that felt good. Biased, factually suspect, unrelated to anything, but that's par for the course.

That's because you're not seeing a dmesg breakdown of the process, I suspect. I totally understand. And just like the shell to point-n-clickers, using the recovery console can be frustrating and foreign (and way underpowered) for fixing things.

It's a welcome change, for sure.
(But I think we scared away the others.)

I wonder what we could call the current twist of the discussion for a new thread to attract some others? I wonder if they're reading? I know there are plenty of others who would have input.

[1] But what determines if the option shows up? My experience has been rather hit/miss, mostly the latter.

There are two types of repairs: the one called a "repair" that really is not much of a repair so much as a "try to get not-so-bad things working," and the other one that comes up when you choose to install the OS and it detects a previous install. That second option actually 'repairs' the boot configuration and some system files, which is good in that it gets the OS to boot, bad in that updates are lost. The intrepid usually try the Recovery Console first (not that I'm always intrepid).

[2] Just to show where I come from: If FreeBSD can't find the kernel, it asks what device it should mount as / .You even get a list of alternatives. After that, it should boot fairly normally, and it's just a case remembering to change the relevant fstab line to avoid it happening again.
And do feel free to prove me wrong by showing me a simple way to fix this from the repair console.

Have you tried things like this?

[3] As long as the kernel starts, the root FS is mounted succesfully and I get a tty, I can fix things in a *BSD. I can skip the graphics. I can skip almost all the drivers or load alternates. (I could load a kernel from a CD and a few modules of a floppy if the situation required it). I can skip the init scripts. At worst it's so primitive a SysV-hacker would feel at home, but that is infinitely preferable to a system that doesn't boot at all. I don't think I've ever gotten a FreeBSD installation into a state that couldn't be fixed with only the tools it gives you.
(Doing make installworld with a broken world build would probably do it, since there's no easy way to recover from most/all tools not working. Also, I'll have to count the install CD as "the tools it gives you" when it comes to overwritten bootloaders.)

See, I can do similar things with the Windows tools and adding some stuff to the recovery console, along with using the CD as a tool as well. To-may-to, to-mah-to.

You know, maybe a thread discussing the different tactics used to repair problems with the OS getting hosed on different systems would get more participation (and, I'm sure, a few trolls).