Hey all. Captive-NTFS has been in the portage tree for a while. There is also a precompiled package that works on AMD64 systems, which is the ebuild I am attaching. For those who don't know Captive-NTFS, it is a program that uses ReactOS compatibility code to load the Windows NTFS filesystem driver, allowing full (if somewhat inefficient) read/write access to native NTFS volumes. I'm proposing adding this to sys-fs as captive-static. My ebuild may also not be perfect, so if you guys could check to make sure I did everything kosher, that'd be great.
Created attachment 83747 [details] Ebuild for captive-static
IIRC this doesn't work on amd64 (and the tarball is marked as i386). Can someone w/ amd64 verify, please?
Sorry, forgot to mention that this package is for multilib systems only. *embarrassed* It is confirmed running on several AMD64 systems with multilib, but AFAIK there is no native 64-bit equivalent.
can you please try using the source ebuild and sticking ABI=x86 somewhere in there? I have been using it in /usr/portage/net-dialup/slmodem/slmodem-2.9.11_pre20051101.ebuild and it works. I would really prefer a source build since we are talking about gentoo here :)
I tried. It fails during configure with an error about popt. I would greatly prefer if we could get the source package to work as well, but I don't know if it will. As an aside, I didn't know you could stick ABI=x86 into a package and have it build the 32-bit version, that's pretty cool :)
ebuild works for me :) txh great job....
(In reply to comment #5) > I tried. It fails during configure with an error about popt. I would greatly > prefer if we could get the source package to work as well, but I don't know if > it will. As an aside, I didn't know you could stick ABI=x86 into a package and > have it build the 32-bit version, that's pretty cool :) Any reason why you amd64 guys don't rather use latest sys-fs/ntfsprogs with USE=fuse? Have had much better results for writing to NTFS with that one on x86 as well.
(In reply to comment #7) > (In reply to comment #5) > > I tried. It fails during configure with an error about popt. I would greatly > > prefer if we could get the source package to work as well, but I don't know if > > it will. As an aside, I didn't know you could stick ABI=x86 into a package and > > have it build the 32-bit version, that's pretty cool :) > > Any reason why you amd64 guys don't rather use latest sys-fs/ntfsprogs with > USE=fuse? Have had much better results for writing to NTFS with that one on x86 > as well. > One good reason is that some of us don't know about it. ;) I suppose there's no real reason why we CAN'T, it's just an option that hasn't been presented to us. It may not help much that the implementation of ntfsprogs is *technically* incomplete, even if functional. (This according to their documentation) I'm willing to give it a try, at least, and see how it compares.
(In reply to comment #8) > > Any reason why you amd64 guys don't rather use latest sys-fs/ntfsprogs with > > USE=fuse? Have had much better results for writing to NTFS with that one on x86 > > as well. > > > One good reason is that some of us don't know about it. ;) I suppose there's no > real reason why we CAN'T, it's just an option that hasn't been presented to us. > It may not help much that the implementation of ntfsprogs is *technically* > incomplete, even if functional. (This according to their documentation) I'm > willing to give it a try, at least, and see how it compares. > You might find this link interesting: http://www.debian-administration.org/articles/367
(In reply to comment #9) > (In reply to comment #8) > > It may not help much that the implementation of ntfsprogs is *technically* > > incomplete, even if functional. (This according to their documentation) I'm > > willing to give it a try, at least, and see how it compares. > > > > You might find this link interesting: > > http://www.debian-administration.org/articles/367 > I already knew it was slow and had potential for problems - I mean, it uses the Windows driver, for cryin' out loud. That was quite enlightening, though.
now with ntfs3g in place there is no more point in fixing this.
