Captive
Captive provides full read/write access to NTFS disk drives in the WINE way by using the original Microsoft Windows ntfs.sys driver. It emulates the required subsystems of the Microsoft Windows kernel by reusing one of the original ntoskrnl.exe, ReactOS parts, or this project's own reimplementations on a case by case basis. Involvement of the original driver files was chosen to achieve the best and unprecedented filesystem compatibility and safety.
| Tags | Filesystems |
|---|---|
| Licenses | GPL |
| Operating Systems | POSIX Linux |
| Implementation | Perl C Assembly |
Recent releases
- 27 Jan 2006 01:22
Changes: Automatic sandbox restarting was fixed to avoid "disconnected mounts". Charset support for locale filenames was fixed. captive-install-acquire(1) was fixed to run at all again. Other FUSE client fixes were made regarding timestamps, user mounts, and automatic modprobe(8)ing.
- 29 Dec 2005 01:13
Changes: Support for the Linux kernel's FUSE interface was added. A script for properly unmounting NTFS filesystems on shutdown was added. Updates were made for recent Microsoft binaries and GNU/Linux build environment compatibility.
- 18 Jan 2004 14:16
Changes: This release fixes truncation of files if they are being overwritten. It allows reading of hidden/system NTFS files, mounting of some versions of NT 4.0 NTFS disk drives, and mounting the devices of /dev/ataraid/.
- 13 Dec 2003 23:31
Changes: This release features Unicode/UTF8 localized filename support, and fixes incompatibilies with various Linux distributions.
- 08 Dec 2003 04:13
Changes: This release fixes NTFS unmount, thereby no longer invoking auto-chkdsk when Windows boots. Loss from moving a directory into itself is now prevented. Various NTFS operations safe refusals have been also fixed.
- All comments
Recent commentsRe: sandbox??
> Namely, I was able to remove things, I
> even haven't seen them listed, BUT THEN
> THEY APPEARED AGAIN )))
> Finally, I was invoking sync - umount -
> mount after almost any operation on the
> disks. Does it have to do something with
> sandbox? Is it ok?
* Always umount the drive before shutting down GNU/Linux (probably not your problem).
* Check your system logs for any Captive messages. Captive will rather give up (=>files reappear) the modifications if there is a risk of corrupting the drive.
* "Sandbox" is required to be turned on for any safe operations of Captive. Running without "sandbox" is only for debugging purposes as it may corrupt your drive.
* Always use the captive-cmdline(1) client only as the Linux kernel interface (for mount(8)) always sucked either as LUFS or as FUSE just because Linux kernel sucks.
sandbox??
Hi Jan!
Thank you very much for this release. I decided to get rid of MSWin, and this was a very useful tool to rearrange NTFS partitions.
There was numerous isuues, though. Namely, I was able to remove things, I even haven't seen them listed, BUT THEN THEY APPEARED AGAIN )))
Finally, I was invoking sync - umount - mount after almost any operation on the disks. Does it have to do something with sandbox? Is it ok?
Re: Very well put together
> I do notice the
> initial mounting process does take
> slightly longer than the Linux-NTFS
> project. But, once I'm past that, it's
> quite transparent.
It takes some time to internally boot the Microsoft Windows subsystem. :-)
> One question I have for you, how would I
> allow normal users to access those
> drives?
Version 1.1 needs "mount -o fmask=666,dmask=777". Default of v1.1 is 600/700, Next v1.1.1 will default to the common 644/755 (root/owner r/w, users r/o).
Very well put together
I commend you for this project. I am currently using this on my XP NTFS partitions and I am impressed that I can actually move, edit, and remove files and directories with no apparent ill effects. This is very nice indeed.
I initially was skeptical because it uses wine and parts of ReactOS (I have messed with this OS a few times), but you have proved me wrong. I have noticed no lag on my system. I do notice the initial mounting process does take slightly longer than the Linux-NTFS project. But, once I'm past that, it's quite transparent.
One question I have for you, how would I allow normal users to access those drives? It would seem that user=<uid> is of no effect. I may be doing something wrong, but captive-cmdline does report user=<uid>.