This is a Microsoft Windows NT kernel emulation for NTFS disk access. You can do completely safe NTFS read/write under linux with this. Unlike other solutions that can do the same, this one has full write compatibility and is open source (for the most part, not including the Microsoft drivers it downloads). The ebuilds would have to include: captive-1.0.1 captive-lufs-1.0.1 captive-install-1.0.1 Also something like lufs-0.9.6-1captive6 would need to be included since this application needs a 'captive' version of lufs. So a little work to do, but many people would benefit from full NTFS access :) Reproducible: Always Steps to Reproduce:
You provide the ebuilds, and I'm sure somebody will be happy to add them. At the moment the kernel team is pretty overloaded, so I wouldn't expect immediate action on this.
I'm happy to add the ebuild to portage, but please provide it, and more importantly, *test* it.
Well, actually, I think the captive-install is part of the main captive package. It looks like it would be broken down into 'captive', 'lufs', and 'gnome-vfs-httpcaptive'. (see http://www.jankratochvil.net/project/captive/CVS.html.pl#source) In any case, I'm working on ebuilds right now, if you could just tell me which category each one goes into. :)
Created attachment 21587 [details] captive-lufs preliminary ebuild Here's the ebuild for captive-lufs. This will be obseleted once the Captive patches make their way into the main lufs tree, but for now it's easier to have a seperate ebuild that captive can depend on. We can then change the dependancies of the captive ebuild once the main lufs source includes the required code.
Created attachment 21591 [details] preliminary captive-1.1.2 ebuild Well, here it is, it installs and runs on my box. There are some errors with the version of ntfs drivers you're using, but this should be enough to get you up and running. This includes the GUI tool to scan your mounted filesystems for the Windows binaries and set up the Captive environment.
Created attachment 21937 [details] ebuild for new captive version. captive-1.1.3.2 ebuild. Captive is still very much in testing, so while this does properly install captive on the target machine, there's no guarantee it'll work correctly (or even at all).
Created attachment 22379 [details] Ebuild for new 1.1.4 version with some fixes This build works fairly well. The only problem I noticed is that while it's building captive, it requires you to press enter several times due to ldconfig failing in the makefiles. However, all the dependencies are met except ntfsprogs-gnomevfs I believe, which is only supposed to be needed for debian. Without this package it doesn't autodetect your NTFS partitions so you have to mount them manually. This should be easy to do, especially for a gentoo user. Instead of using ntfs as the type, you use captive-ntfs. This ebuild is almost ready to go into portage after the above have been fixed. Perhaps in the future we could add a useflag so experts could install the program without the gui tools and the gnome dependencies. As for the program itself, I tested it on my two NTFS partitions and it works very nicely. The only problem I had was reading hidden system files, which is not a huge deal. If anyone wants to improve the ebuilds, let me know :)
Created attachment 22380 [details] Ebuild for new captive-lufs version 0.9.7-r8 This is just the updated captive-lufs needed by the new 1.1.4 version. No problems with this build.
Created attachment 22383 [details] Ebuild for gnome-vfs-httpcaptive 2.3.8-r2 This is the package for the httpcaptive:// gnome vfs. It is needed to download the service pack for [the operating system from Redmond] until seek() function support for http:// handler in gnome. There has been a bug submitted about this. If anyone is interested in voting for this bug, it's #121194 at gnome's bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=121194
Warning, the ntfs driver is unable to truncate files! This should be fixed in 1.1.5. You should wait for this version before you put it in the portage tree.
I have noticed high memory usage in captive-sandbox after copying files from a ntfs partition to a ext3 partition. I have also noticed that lufsd-bin will eventually use up all available memory on my system if given enough time.
The standard memory usage is at least 20mb, it might increase a bit with more usage due to some MFT stuff that I don't know about. Lufsd should not eat up your memory like that. Could you give me an estimate on how long it takes for it to do that? (days, hours) I've only used it for several hours in a row, but I have not had any memory leaks. I could even play Call of Duty under wine for a very long periods on the ntfs partition without any problems or performance hinderances. If you are running the 2.6 kernel, I've heard a few people mention some problems with lufsd and slow writing speeds.
There is a general problem with applications scanning (opening) too many files - all remain open and their NT Cache Manager memory areas remain allocated. Unfortunately I am currently busy with my job, hacking details upon request.
For some reason it just hangs at when when I try to mount a drive. sixisnine # mount -t captive-ntfs /dev/hda1 /mnt/winxp Captive NTFS v1.1.4. Check a new version at: http://www.jankratochvil.net/
Created attachment 24138 [details] EBuild for 1.1.5 New version, but still with the ldconfig-issue...
I am not aware of the ebuild process but in the case it requests ENTER (therefore user 'root' and empty $DESTDIR), please try: make install DESTDIR=/ This way it should have no sideeffects (not tried now).
Created attachment 24139 [details] Ebuild captive 1.1.5 fixed Fixed ldconfig-issue. Thanks to Jan. Worked for me.
Created attachment 24143 [details] fixed EBuild 1.1.5 ... again ;-) minor bugfix removes captive user/group when unmerging
Hi, i get a sanbox access violation when using the fixed ebuild. ;(
Here the error: make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/var/tmp/portage/captive-1.1.5/work/captive-1.1.5' make[1]: Leaving directory `/var/tmp/portage/captive-1.1.5/work/captive-1.1.5' --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-captive-1.1.5-29458.log" unlink: /usr/spool/sockets/X11/2701 --------------------------------------------------------------------------------
more bugs to come: 1) captive-lufs: # /usr/share/lufs/prepmod (needs to by run) it requires a directory /usr/src/kernel-headers-2.4.$X (X = kernel you are running) this can be managed by: # ln -s /usr/src/linux/include /usr/src/kernel-headers-2.4.$X after prepmod: # modules-update It would also be nice to tell the user that calling prepmod is a required step after a kernel upgrade! 2)captive: # mkdir -p /var/lib/captive/tmp # mkdir -p /var/lib/lib/captive (this is braindamed somehow... ;) ) # cp captive-1.1.5/src/install/acquire/w32-mod-id.captivemodid.xml /etc (else captive-install-acquire won't start - btw. i DON'T like a file called "w32-mod-id.captivemodid.xml" in /etc - can you check if this can be put elseware?) 3) There is no link to "liblufs-captivefs-1.1.5.so" as "liblufs-captivefs.so" in /usr/lib. 4) Can you distribute "ext2fsd.sys" in files in your ebuild? It's legal to distribute this file - Maybe you can download it. It needs to be installed in "/var/lib/lib/captive". 5) maybe you can add a kind of test: # mkdir /tmp/nfts # cd /tmp/ntfs # dd if=/dev/zero of=ntfs.img bs=$((1024 * 1024)) count=128 (creates a 128mb file) # /usr/sbin/mkntfs -F ntfs.img # mount -t captive-ntfs /tmp/nfts/ntfs.img Good work anyway ;) Happy bugfixing.
just tested to emerge -C captive captive-lufs && emerge captive and that worked.
sure it works ;) you have the directories that i mentioned that are missing...
might also wanna change the einstall line to make DESTDIR=${D} install || die built it in a livecd enviroment and einstall made it merge to /var/tmp, though normal make works. (thanks to jstubbs on gentoo-dev for that solution)
> 1) captive-lufs: > > # /usr/share/lufs/prepmod (needs to by run) > it requires a directory /usr/src/kernel-headers-2.4.$X (X = kernel you are running) > this can be managed by: > # ln -s /usr/src/linux/include /usr/src/kernel-headers-2.4.$X > after prepmod: > # modules-update /usr/src/linux/include should be checked+used automatically by 'prepmod'. Please send me your full standalone 'prepmod' output if it currently fails. > It would also be nice to tell the user that calling prepmod is a required step after a kernel upgrade! Captive uses 'lufsd-captive' being wrapped by 'prepmod' and therefore it is no need for the user to run it manually as it is run automatically before any captive-ntfs mount. Outside of 'captive-static' build it is the 'lufsd' binary which is wrapped by 'lufs-*captive' package. > 2)captive: ... > # mkdir -p /var/lib/lib/captive (this is braindamed somehow... ;) ) You need to override '--localstatedir' for configure. Some systems have it somehow incompatible - it is needed for Mandrake but it is not needed for RedHat/SuSE etc. > # cp captive-1.1.5/src/install/acquire/w32-mod-id.captivemodid.xml /etc > (else captive-install-acquire won't start - btw. i DON'T like a file called "w32-mod-id.captivemodid.xml" in /etc - can you check if this can be put elseware?) It is installed to '--sysconfdir', you can override it. BTW do you know better directory where it should be installed? It is a configuration file.
another minor problem, if you upgrade/reemerge it, it'll unemerge after the merge, and remove the captive user and group.
Watching ebuilds with interest. Perhaps a subdirectory for captive? /etc/fonts has xml but no one minds. Or a name change to something less verbose. /usr/share I guess would work although less logical for config.
Created attachment 27686 [details] EBuilds using FUSE These ebuilds use lufis/fuse instead of captive-lufs. Do not use captive-lufs anymore. (unemerge it) I didn't have much time to test it (not very nice ebuilds). You now need "lufis" to mount your ntfs drive.
FYI: There's a FUSE ebuild submitted as bug 45067.
Ok thanks. You should use that FUSE ebuild instead.
Created attachment 27688 [details] Captive ebuilds using FUSE (removed FUSE ebuild) Removed fuse ebuild.
Created attachment 27754 [details] lufis-0.2.ebuild There were bugs and violation of ebuild authoring guide in lufis ebuild, attached one should be fixed.
Comment on attachment 22380 [details] Ebuild for new captive-lufs version 0.9.7-r8 use lufis instead of fuse/lufs
Created attachment 27838 [details] captive-1.1.5.ebuild with installation fixes This is modified ebuild from the tar file (sic!) with lufis version. Changes: - Fixes /var/lib/lib/captive problem (thanks Jan!). - On my system, old ebuild included some /var/tmp/portage/... files among installed files, because there was "einstall DESTDIR=${D}" line. Changed to "emake install DESTDIR=${D}" to correct it. - Post-installation step tells the user to remove "captive" user&group manually This together with fixed lufis ebuild should deprecate attachment 27688 [details], but I don't have permission to mark it as such myself.
So the newest lufis ebuild and the newest captive ebuild are the only two that are needed anymore? I got lost reading through this bug with all of the changes. I'll be happy to add it to portage (after I test it).
The lufis and captive ebuilds are needed, as well as gnome-vfs-httpcaptive. I'm not sure if gnome-vfs-httpcaptive is still needed with the latest gnome-vfs. It was required earlier for the installation program because there was no seek() function support for the http:// handler. The author submitted a bug on this to gnome, http://bugzilla.gnome.org/show_bug.cgi?id=121194. Looks like it still has not been implemented yet.
My
My 0.02: Perhaps it would be a good idea to provide an ebuild for captive-static, as no KDE user will be eager to install gnome to be able to use captive. I don't know how Knoppix handles this, but it has captive installed without Gnome.
You don't need gnome to install it, just some libraries to get gnome-vfs and gnome-vfs-httpcaptive. Those libraries are needed because of the way the configuration application is used. I did not have gnome installed, and the captive ebuild didn't need any libs it did not already have (since some other applicatiosn require gnome-vfs). It should be ok for a kde user. We could perhaps provide a "gui" use flag to control whether the gui application gets installed or not.
Created attachment 32262 [details] newer captive-1.1.5 with sandbox fix The other ebuilds broke the sandbox when certain version of Xvnc are there.. I removed the test from the configure script. Its not needed anyways.. And it doesnt seem to work with the sys-fs/lufs that's in portage.. it really does require its own version.. so this ebuild is still wrong..
In what sense is the ebuild wrong? The lufs that is in portage does not have the necessary patches that the captive one does, therefore that's the only one that can be used at the moment.
the ebuild says it requires the "normal" lufs while captive really requires the patched one..
Created attachment 34905 [details] Error installing ebuild... help please?
well... rename the captive-ntfs dir to captive, or rename the ebuild.
you should add a PORTDIR_OVERLAY="/usr/local/portage" to your /etc/make.conf and leave /usr/portage unchanged.
will this eventually get into portage?
i havent tried this yet hope too in couple of days tho whats the current status of this? i see the last comment that was working on the ebuild was over 2 months ago so that mean its all good and should make its way to portage?
I tried several combinations captive-lufs + captive --->> mounting a filesystem, but not saving changes (mount command is not going back to shell again) captive + lufs ----->> could not parse options! Which are the working ebuilds and which other packages are needed for it? i.e. I found lufis ebuild here, but no sys-fs/fuse-1.1 (dep) ebuild nowhere (only app-emul/fuse-0.6*) Missed I something installing captive ? Could one who got it working right write a short HOWTO install captive with everything? This would reallly be great? Will gentoo include captive into portage one day (maybe next month)? Thanx for everybody developing in here
Like many other ebuilds floating around here, we're simply waiting for a developer to step up and submit them to portage. The problem is that it's not just a matter of commiting the ebuild, that developer then has to agree to maintain the ebuild (fix bugs, new versions, etc.). I don't have enough time to pick up any more packages right now, and I think the others on the kernel team are in a similar position. The best thing you can do right now is continue developing and testing these ebuilds. You could also go over the developer docs and make sure they conform to our standards. On the other hand, if anyone thinks they have enough experience and motivation to pick up a few kernel module ebuilds like this one then please email me and I'll investigate and pass you onto the correct people.
ok, I got it working, but there are some "fusermount:" messages, how can I avoid them, or why are they there? I do it as root so capabilitiey should be no problem. ~ # lufis "fs=captivefs,dir_cache_entries=0,image=/dev/hda3,captive_options=--rw ;--load-module=/var/lib/captive/ntoskrnl.exe;--filesystem=/var/lib/captive/ntfs.sys;--sandbox-server=/usr/sbin/captive-sandbox-server;" /mnt/hda3 -s ~ # fusermount: failed to set capabilities: Operation not permitted fusermount: failed to restore capabilities: Operation not permitted ~ # ls /mnt/hda3 Captive NTFS v1.1.5. Check a new version at: http://www.jankratochvil.net/ captive-lufs_1.1.5_i386.deb engage.mpeg x ~ # umount /mnt/hda3 fusermount: failed to set capabilities: Operation not permitted fusermount: failed to restore capabilities: Operation not permitted
Created attachment 41919 [details] captive.tar.bz2 This contains all the ebuilds necessary for captive. Howto: 1) echo "PORTDIR_OVERLAY=/usr/local/portage" >> /etc/make.conf 2) mkdir /usr/local/portage 3) tar xvjf captive.tar.bz2 4) ACCEPT_KEYWORDS=~x86 emerge -va captive 5) ACCEPT_KEYWORDS=~x86 emerge -va lufis 6) captive-install-acquire 7) lufis "fs=captivefs,dir_cache_entries=0,image=/dev/hda1,captive_options=--rw;--load-module=/var/lib/captive/ntoskrnl.exe;--filesystem=/var/lib/captive/ntfs.sys;--sandbox-server=/usr/sbin/captive-sandbox-server;" /mnt/ntfs -s Please report any problems you might see with this.
When it tries to emerge lufs it craps out and sends this: >>> Merging sys-fs/lufs-0.9.7-r3 to / --- /etc/ --- /etc/autofs/ >>> /etc/autofs/auto.ftpfs -> /usr/bin/auto.ftpfs >>> /etc/autofs/auto.sshfs -> /usr/bin/auto.sshfs >>> /etc/lufsd.conf --- /sbin/ --- /usr/ --- /usr/bin/ >>> /usr/bin/auto.ftpfs >>> /usr/bin/auto.sshfs Traceback (most recent call last): File "/usr/bin/emerge", line 2991, in ? mydepgraph.merge(mydepgraph.altlist()) File "/usr/bin/emerge", line 1839, in merge retval=portage.doebuild(y,"merge",myroot,self.pkgsettings,edebug) File "/usr/lib/portage/pym/portage.py", line 2562, in doebuild return merge(mysettings["CATEGORY"],mysettings["PF"],mysettings["D"],mysettings["BUILDDIR"]+"/build-info",myroot,mysettings,myebuild=mysettings["EBUILD"]) File "/usr/lib/portage/pym/portage.py", line 2695, in merge return mylink.merge(pkgloc,infloc,myroot,myebuild) File "/usr/lib/portage/pym/portage.py", line 6670, in merge return self.treewalk(mergeroot,myroot,inforoot,myebuild,cleanup=cleanup) File "/usr/lib/portage/pym/portage.py", line 6297, in treewalk if self.mergeme(srcroot,destroot,outfile,secondhand,"",cfgfiledict,mymtime): File "/usr/lib/portage/pym/portage.py", line 6536, in mergeme if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime): File "/usr/lib/portage/pym/portage.py", line 6536, in mergeme if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime): File "/usr/lib/portage/pym/portage.py", line 6551, in mergeme elif stat.S_ISREG(mydmode) or (stat.S_ISLNK(mydmode) and stat.S_ISREG(os.stat(mydest)[stat.ST_MODE])): OSError: [Errno 2] No such file or directory: '/usr/bin/lufsd' So essentially, it's saying at the end that file doesn't exist... but it does: tux captive # ls /usr/bin/lufsd /usr/bin/lufsd Any ideas?
Nevermind on the above comment; went to where the source was installed for lufs and did a "make uninstall" then remerged it and that seemed to fix it.
while emerging gnome-vfs-httpcaptive-2.3.8-r2 like in comment #50, i get: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -pthread -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_FILE_OFFSET_BITS=64 -D_BSD_SOURCE -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DG_DISABLE_DEPRECATED -DDATADIR=\"/usr/share\" -DPREFIX=\"/usr\" -DLIBDIR=\"/usr/lib\" -DSYSCONFDIR=\"/etc\" -DG_LOG_DOMAIN=\"gnome-vfs-modules\" -pthread -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 -I/usr/include/gnome-vfs-2.0 -I/usr/include/gnome-vfs-module-2.0 -I/usr/lib/gnome-vfs-2.0/include -march=pentium3 -O3 -pipe -fomit-frame-pointer -c http-authn.c -MT libhttpcaptive_la-http-authn.lo -MD -MP -MF .deps/libhttpcaptive_la-http-authn.TPlo -fPIC -DPIC -o .libs/libhttpcaptive_la-http-authn.o http-method.c: In function `get_header': http-method.c:612: error: too few arguments to function `gnome_vfs_socket_buffer_read' http-method.c:628: error: too few arguments to function `gnome_vfs_socket_buffer_peekc' http-method.c: In function `https_proxy': http-method.c:1232: error: too few arguments to function `gnome_vfs_socket_write' http-method.c:1236: error: too few arguments to function `gnome_vfs_socket_close' http-method.c:1243: error: too few arguments to function `gnome_vfs_socket_write' http-method.c:1248: error: too few arguments to function `gnome_vfs_socket_close' http-method.c:1255: error: too few arguments to function `gnome_vfs_socket_read' http-method.c:1258: error: too few arguments to function `gnome_vfs_socket_close' http-method.c:1264: error: too few arguments to function `gnome_vfs_socket_close' http-method.c:1272: error: too few arguments to function `gnome_vfs_socket_close' http-method.c:1282: error: too few arguments to function `gnome_vfs_ssl_create_from_fd' http-method.c:1285: error: too few arguments to function `gnome_vfs_socket_close' http-method.c: In function `connect_to_uri': http-method.c:1381: error: too few arguments to function `gnome_vfs_ssl_create' http-method.c:1403: error: too few arguments to function `gnome_vfs_socket_close' http-method.c: In function `xmit_request': http-method.c:1484: error: too few arguments to function `gnome_vfs_socket_buffer_write' http-method.c:1495: error: too few arguments to function `gnome_vfs_socket_buffer_write' http-method.c:1502: error: too few arguments to function `gnome_vfs_socket_buffer_flush' http-method.c: In function `make_request': http-method.c:1638: error: too few arguments to function `gnome_vfs_socket_buffer_destroy' http-method.c: In function `http_handle_close': http-method.c:1653: error: too few arguments to function `gnome_vfs_socket_buffer_flush' http-method.c:1655: error: too few arguments to function `gnome_vfs_socket_buffer_destroy' http-method.c: In function `do_read': http-method.c:1916: error: too few arguments to function `gnome_vfs_socket_buffer_read' http-method.c:1946: error: too few arguments to function `gnome_vfs_socket_buffer_read' make[2]: *** [libhttpcaptive_la-http-method.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... gnome-vfs-2.8.1-r2 is already installed. Whats wrong with this? Also, it'd be great to have a captive without all these gnome dependencies. thanks for all your work!
The gnome-vfs-httpcaptive incompatibility in comment #53 should no longer be relevant as the whole gnome-vfs-httpcaptive patch is now obsolete: According to its pending Gnome Bug http://bugzilla.gnome.org/show_bug.cgi?id=121194 the seek() support has been already integrated into the latest (FIXME: which version?) GnomeVFS.
I would like to add this, but I have some problems with the gnome-vfs-httpcaptive package. That is an old version of gnome-vfs-httpcaptive package which is patched to supports the seeks, but the gnome-bug was solved by implementing it in another way. I dont like to install the old gnome-vfs-httpcaptive package so we basically have 2 options to get captive in the tree: a) port the gnome-vfs-patch to the latest gnome-vfs b) change captive Maybe someone here wants to become captive maintainer, because it is currently not maintained?
captive-acquire-install(1) will try 'httpcaptive' scheme only in the case of unsupported seek() by the default 'http' scheme. See captive/src/install/acquire/cabinet.c:325. I expect simple drop of 'gnome-vfs-httpcaptive' from the packages required by 'captive' is fine with recent Gnome-VFS already supporting 'http' seek().
With gnome-vfs-2.8.3, the latest in portage, I get an "Error scanning sub-tree of http://download.ms...exe No directory" warning window when I try to start the download. Another problem with this package is that the huge gnome dependancies cant be disabled on build-time. I assume most of the people dont use captive with gnome-vfs but with lufis/fuse to mount it.
OK, I was not aware of "Error scanning sub-tree", some other compatibility problem is apparently there. Using "gnome-vfs-httpcaptive" just workarounds the issue by providing old Gnome-VFS still compatibile with captive-install-acquire(1). Also all the optional Gnome dependencies are "optional" - "configure" will succeed and omit some parts which are not needed. GnomeVFS2, GLib2 and ORBit2 are used insternally by Captive itself. One can choose other packages (such as reimplementVFS+NSPR+MICO) or you can reimplement them all from scratch. I choose the Gnome ones. BTW Linux kernel compatibility is currently broken due to the unmaintained LUFS interface. Someone should write FUSE interface instead. It looks funny for me that really noone wrote that FUSE interface yet for the last year.
I think gnome-vfs-captive is no longer necessary... you can just use the regular gnome-vfs ... (from gnome 2.8). That said, no captive is not in the tree.... because no one wants to maintain it.. Feel free to do so ;)
Created attachment 43992 [details, diff] do-not-check-for-lufsd.patch The lufis in portage fully replaces lufs, and does not require lufs to be installed, so there is in fact no need to rewrite anything. With the applied patch I can also avoid that captive errors out on compile due to missing lufsd (the lufs headers get installed by lufis). We plan to remove lufs from the tree in favour of lufis. So this issue is solved. But the problem still remains. I cant use captive without the MS-files, and I cant download and use them without te gnome gui, so I unfortunately cant add captive :( Another thing, what I wonder about is, why captive takes so long to compile?
>But the problem still remains. I cant use captive without the MS-files, and I >cant download and use them without te gnome gui, so I unfortunately cant add Isn't it possible to download the MS file from a url? I think it needs to be extracted afterwards which could be done without the gnome gui. There really don't have to be any gnome dependencies in order to get it to work. Is there no curses gui to install the MS-files?
Currently Gnome-VFS 'http' seek() is used to download only a part of the servicepack, therefore a simple "download" is worse solution. There is no "curses" captive-install-acquire(1) but there it runs in readline(3) way if no X is available. The bug is libgnomeui is still required to compile captive-install-acquire(1) even just to use the readline(3) UI. Optional GUI version omit if no libgnomeui is found is implemented in the newer version of the build framework used in my http://www.jankratochvil.net/project/udpgate/ although I did not backport it to Captive.
I follow this: ------- Additional Comment #50 From Stefan Schweizer 2004-10-15 14:44 PST ------- Created an attachment (id=41919) [edit] captive.tar.bz2 This contains all the ebuilds necessary for captive. Howto: 1) echo "PORTDIR_OVERLAY=/usr/local/portage" >> /etc/make.conf 2) mkdir /usr/local/portage 3) tar xvjf captive.tar.bz2 4) ACCEPT_KEYWORDS=~x86 emerge -va captive 5) ACCEPT_KEYWORDS=~x86 emerge -va lufis 6) captive-install-acquire 7) lufis "fs=captivefs,dir_cache_entries=0,image=/dev/hda1,captive_options=--rw;--load-module=/var/lib/captive/ntoskrnl.exe;--filesystem=/var/lib/captive/ntfs.sys;--sandbox-server=/usr/sbin/captive-sandbox-server;" /mnt/ntfs -s Please report any problems you might see with this. But, I always obtain this: jo-jo_machine ~ # mount /dev/hda7 on / type reiserfs (rw,noatime) devfs on /dev type devfs (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw) none on /dev/shm type tmpfs (rw) none on /proc/bus/usb type usbfs (rw) lufis on /mnt/ntfs type fuse (rw,nosuid,nodev) jo-jo_machine ~ # ls /mnt/ntfs ls: /mnt/ntfs: Transport endpoint is not connected jo-jo_machine ~ #
Me and a colleague of mine are experiencing the same error in step 4). Emerge gnome-vfs-httpcaptive results in the "too few arguments to function 'gnome_vfs_socket_*'" failure. Is there a special version of gnome-vfs required?
!!! Captive currently does not work !!! It seems we cant install the old gnome-vfs-httpcaptive package, so we need to modify the captive package to work with the current gnome-vfs. I wont do it, so everyone is free to do it.
Thanks for your patience. I added this to portage with a gnome-vfs-2.6+gnome-vfs-httpcaptive dep. We still need a volunteer to port it to gnome-vfs-2.8 (will make gnome-vfs-httpcaptive superfluous)
closing
Created attachment 48015 [details, diff] Patch to work with gnome-vfs-2.8 I've just made a hackish little patch against gnome-vfs-httpcaptive to at least get this thing running with gnome-vfs-2.8.x. gnome-vfs-httpcaptive is still in the picture, I just wanted something quick to make it work. And it does that :) updated .ebuild posted next.
Created attachment 48016 [details] New ebuild using the patch in the previous post. Works well for me.
Can you please open up a new bug for your nice patch? (I cant fix this bug a second time) Also it would be nice if you could post a diff against the old ebuild, because I know how my ebuild looks like and I am interested in your changes :)
