Mac OS X and Testing Applications on Case Sensitive File Systems - macos

I have two MacBook Pros, but they shipped with a case-insensitive file systems. I would like to test a few of my utilities on a case-sensitive file system. Is there anyway to turn case-sensitivity on per application? Perhaps there is another solution that does not require a re-format of the hard drive?
I also read Technical Note TN2096: Debugging Case-Sensitivity Bugs in Applications. But it does not detail how to set up a test environment.

There is no way to "turn on case-sensitivity" for a single application. The filesystem structure on your volume is what's case-sensitive or not.
You can use Disk Utility to set this up, in a couple of different ways:
If you're just testing reading and writing files: make a disk image, using the format "Mac OS Extended (Case-sensitive, Journaled)". Mount that disk image and make your app use it.
If you want to test on a system booted from a case-sensitive filesystem: add a partition to your drive, choose the case-sensitive format for the new partition, then install OS X on it. Or use an external disk.
I'm sure there are more tricky ways, but those should get you started.

Related

How to modally lock a macOS volume for exclusive read/write access?

I am writing a disk tool that needs to be able to read and possibly modify a live volume.
If the volume is in use, e.g. if it's the boot volume, one cannot simply unmount the volume to perform these operations.
Disk Utility (or the underlying diskutil tool) is able to lock a mounted volume for this purpose when it runs First Aid or when it resizes the startup volume through the "Partitions" dialog.
What API can I use in order to accomplish the same? I.e. what calls do I have to make to have the volume locked (and pending writes flushed), and, optionally, how do I best lock the UI so that the user can't accidentally use other apps that attempt to modify the volume in the meantime?
I am okay with private frameworks and other undocumented ways. This is for a repair program, after all. It won't appear in the Mac App Store ;)
It appears that fcntl (fd, F_FREEZE_FS) is the solution.
I found this call by looking into the code of the command fsck_apfs. It actually offers the "-l" option for "live fsck (lock down for verify-only)".
And now that I know what to look for, I realize that it's also documented in Amit Singh's Mac OS X Internals book.

Is creating hardlinks from linux on a ntfs partition viable?

I have found a program that can make you save space by hardlinking files that are actually the same, thus leaving only one copy of the file on the file system with more than one hardlink pointing to it. The program is called hardlink.
This is very nice as I have at last found a way to save space on my backup disk for old backups I have made before I knew about rsync and incremental backups.
After such a lengthy introduction, any reader would expect a question, so here it is:
Would it be safe to use hardlinks to save space on a ntfs partition? The hardlinks would of course be created from Linux, using the hardlink program mentioned above. More precisely, will Windows (any version) be able to then use the files that would have been replaced by hardlinks?
Many thanks
There are hardlinks on Windows. They are created by the CreateHardLink system call in kernel32.dll. As to whether your hardlink program would work over remote shares, I wouldn't know, but a native one or one from cygwin would.
Now the real question is whether or not Windows programs handle them. Even Windows Explorer fails to calculate disk space used for hardlinks correctly.
I did a small test. Creating a hardlink (using 'ln TargetName LinkName') yields the same file at creation time, but after that the file and the hardlink content change independently. I would therefore discourage any use of unix based hard links on an NTFS partition. Use either an Ext4 partition (linux only) or software adapted for windows-like links on NTFS partitioning (windows software or perhaps some linux software if explicitly mentioned).
I guess that the program hardlink will either fail because hard links doesn’t exists on Windows or create Windows shortcuts.

Where is data on a non-persistant Live CD stored?

When I boot up Linux Mint from a Live CD, I am able to save files to the "File System". But where are these files being saved to? Can't be the disc, since it's a CDR. I don't think it's stored in the RAM, because it can only hold so much data and isn't really intended to be used as a "hard drive". The only other option is the hard drive... but it's certainly not saving to any partition on the hard drive I know about, since none of them are mounted. Then where are my files being saved to??
Believe it or not, it's a ramdisk :)
All live distros mount a temporary hard disk in RAM memory. The process is completely user-transparent and is all because of the magic of Linux kernel.
The OS, in fact, first allocates an area of your RAM memory into a virtual device, then mounts it as a regular hard drive in your file system.
Once you reboot, you lose all your data from that ramdrive.
Ramdrive is needed by almost all software running on Live CDs. In fact, almost all programs, in particular desktop managers, are designed in order to write files, even temporary, during their execution.
As an example, there are two ways to run KDE on a Live CD: either modify its code deeply in order to disallow you to change wallpaper etc. (the desktop settings are stored inside ~/.kde) or redeploy it onto a writable file system such as a ramdrive in order to avoid write fails on read-only file systems.
Obviously, you can mount your real HDD or any USB drive into your virtual file system and make all writes to them permanent, but by default no live distro mounts your drives into the root file system, instead they usually mount into specific subdirectories like /mnt, /media, /windows
Hope to have been of help.
It does indeed emulate a disk using RAM; from Wikipedia:
It is able to run without permanent
installation by placing the files that
typically would be stored on a hard
drive into RAM, typically in a RAM
disk, though this does cut down on the
RAM available to applications.
RAM. In Linux, and indeed most unix systems, any kind of device is seen as a file system.
For example, to get memory info on linux you use cat /proc/meminfo, where cat is used to read files. Then, there's all sorts of strange stuff like /dev/random (to read random crap) and /dev/null (to throw away crap). ;-)
To make it persistent - use a USB device - properly formatted and with a special name. See here:
https://help.ubuntu.com/community/LiveCD/Persistence

Is there something like filter driver for Mac OS X?

Windows lets you develop a filter driver to catch file I/O's on VFS. But I can't seem to find something similar for Mac. It does have something called Filter Schemes, but those are for HFS+. Anyone know if there is a way for me to intercept file I/O's on Mac without using programs like MacFUSE?
I found out that Mac OS X does not allow filter drivers at all.
“A stacking file system (sometimes called a filter file system) sits on top of another file system and modifies its behavior in some way. The canonical example of a stacking file system is an encryption file system. You could stack this file system on top of any existing file system to provide encryption support. Apple does not support the development of stacking VFS plug-ins on Mac OS X” (http://developer.apple.com/mac/library/qa/qa2001/qa1242.html)
kauth (introduced in OS X 10.4) is the closest thing to FS filter drivers.
Here is a nice write-up on the various APIs present on Mac OS X. It should be a good starting point.
Link
I'm not at all familier with the Windows technologies that you mention, but it sounds like you might be looking for FSEvents.
http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html
The file system events API provides a
way for your application to ask for
notification when the contents of a
directory hierarchy are modified. For
example, your application can use this
to quickly detect when the user
modifies a file within a project
bundle using another application.
It also provides a lightweight way to
determine whether the contents of a
directory hierarchy have changed since
your application last examined them.
For example, a backup application can
use this to determine what files have
changed since a given time stamp or a
given event ID.
You should read this document if your
application works with a large number
of files—particularly if your
application works with large
hierarchies of files.

Programmatic way to select boot OS?

I'm setting up a test bed where I am testing a device connection across multiple Windows OSs. I can't do it in a VM (cannot virtualize access to device) so I have quite a multi-boot system. I have a script to automate the process, but I want it go ahead and finish, selecting the next OS to boot and run its test.
One problem is that XP/2K3 use boot.ini while Vista and later use BCDEdit. I could manually have two scripts... one for each XP/2K3 to edit boot.ini. And then to BCDEdit for Vista systems. I'd hate having to hardcode each one though, esp if I have to change order and/or toggle off certain OSs depending on the test conditions.
BCDEdit also uses GUID for their entries, meaning setting up on different machines would mean figuring out which GUID to go to next.
Any thoughts or hints? Are there any utilities that help automate this?
I'm assuming your various flavors of Windows are housed on different partitions. Use an Ubuntu LiveCD to install GRUB and write several configuration files, each of which has one OS selected as the default. Make a HD partition for /boot, and store the GRUB configs in the same location.
Each of your Windows partitions will need to install the Ext2 IFS driver, and mount the EXT2 partition you made before as z: or something. Then your test script can do something like:
mountvol z: %bootvolname%
copy /y boot_to_vista_64.lst z:\boot\grub\menu.lst
shutdown -r -f -t 0
%bootvolname% is a bit complicated, and is OS-specific. You'll need to store it with each OS partition, and you can get it by doing mountvol z: /l while that OS is running.

Resources