Description of Problem: there is no ntfs module included with rh7.3, very annoying Version-Release number of selected component (if applicable): How Reproducible: always Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: is it still redhat's position that ntfs-readonly is broken as of kernel 2.4.18-3?
so dear redhat do you plan to hear your customers or not? do you want we all switch to another distribution? fix this!
I agree that ntfs-readonly support should be included by default at least as a module in redhat installations. I know that myself and a couple of my associates would find this extremely useful. NTFS support will become a larger necessity as more people are using Windows XP, which by default uses NTFS. I am sure many users would find built-in NTFS support extremely helpful.
oh believe me I would LOVE to enable ntfs... but it must be legally possible / sensible to do so ;(
has redhat evaluated readonly-ntfs as of kernel 2.4.19? does it still cause data corruption as claimed?
as far as I know it does no longer corrupt data read only
So, from what I gather, it is not legally possible to include NTFS support in the default kernel provided with redhat? I was just wondering since it is included in the kernel source. I have been enabling it by compiling the kernel myself, but I was just wondering why redhat didn't provide it since other distributions (mandrake) do and I know of may people who find it useful. If there is a legal problem, then I understand.
Check out this page for a nice HOWTO to enable ntfs in redhat linux: http://www.getlinuxonline.com/omp/distro/RedHat/ompntfs2.html
Arjan, what is the status of this request? If NTFS read-only is indeed safe, it would be very nice if we could have this by default.
arjan please elaborate on the specific legal objections redhat has to including readonly-ntfs?
Please check with lawyers about this. Inclusion of ntfs.o read-only would be very useful in a future release.
*** Bug 61768 has been marked as a duplicate of this bug. ***
*** Bug 70571 has been marked as a duplicate of this bug. ***
*** Bug 77143 has been marked as a duplicate of this bug. ***
*** Bug 73793 has been marked as a duplicate of this bug. ***
*** Bug 84119 has been marked as a duplicate of this bug. ***
RHL9 includes rdekstop, which was built with reverse engineering of a MS protocol; how is NTFS different?
redhat bundles samba which was also reverse engineered. omitting ntfs but bundling samba+rdesktop seems odd. can someone from redhat please state the exact legal objection redhat has to ntfs, or give the exact contact information for the legal counsel at redhat that is responsible for this conclusion? we are approaching 1 year since the question was posed to redhat, and there is still no answer. further: mandrake, gentoo, suse, lycoris all bundle read-only ntfs...
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/
*** Bug 135741 has been marked as a duplicate of this bug. ***
Reopening against Fedora Core 3, since closing this RFE as a "product doesn't exist" is a huge copout.
The HOWTO mentioned doesn't exist. I get a 404 error on http://www.getlinuxonline.com/omp/distro/RedHat/ompntfs2.html
You can get everything you want from http://linux-ntfs.sourceforge.net/rpm/fedora3.html That includes full RW access to NTFS partitions (for the brave) or RO access for mortals.
*** Bug 147318 has been marked as a duplicate of this bug. ***
After discussion with counsel, we deem the inclusion of NTFS in the Fedora project to be too risky. Patent encumbrance.
*** Bug 154754 has been marked as a duplicate of this bug. ***
*** Bug 156253 has been marked as a duplicate of this bug. ***
*** Bug 157772 has been marked as a duplicate of this bug. ***
*** Bug 165632 has been marked as a duplicate of this bug. ***
*** Bug 166165 has been marked as a duplicate of this bug. ***
It seams that NTFS is no more in ForbiddenItems list → http://fedoraproject.org/wiki/ForbiddenItems?action=diff&rev2=89&rev1=88 Other ntfs related packages are allowed to be in Extras repo: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210840 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211698 Can you enable now ntfs module, please? ntfs-3g is sometimes not an option (iso images on ntfs partition and you want to perform installation from disk drive).
ntfs-3g supports loop mounts (mounting iso image on ntfs partition), moreover you can also statically link it with dietlibc or uClibc and put into an initrd. You can even use NTFS as your root filesystem (only in "single user" mode at present). These are continuously tested and in use by several distros already.
(Moving this from FC3.)
Changing summary from "NTFS cannot be enabled in Fedora" to "NTFS now cosidered acceptable and can should be enabled in Fedora's kernel" due to #30 Re-assigning to kernel-maint I'd like to see the ntfs driver enabled in the kernel-package now, too. I talked to one ntfs driver developer and he said: >If you want to loop-mount a file on NTFS, the kernel driver would be a >better choice. >Examples are putting using a swap file on "C:" (only the latest >ntfs-3g support it, and it may dead-lock, although Szaka won't admit >it). Another example that is not relevant for Fedora is saving the >user settings of a live-cd. > >There is no doubt that the kernel driver is more stable. It only had >bug fixes for some time. ntfs-3g is still under development. The >kernel driver is also faster. If the kernel-developers in Fedora don't want to enable it I'll propose a kmod for Extras that contains the driver. This will look stupid, but it's known as "forcing the issue" (quoting spot from the ntfs driver submission for Extras)
Swap on loopback on top of NTFS may deadlock. This is exactly the reason why direct swap file support on NTFS was implemented recently (i.e. no need for loopback to swap). The read functionality of the kernel is stable, the limited write may have serious problems, for example when truncating runlists. The two drivers share quite many code, except ntfs-3g kept fixing bugs, added new features, and is kept being extensively quality tested: http://www.ntfs-3g.org/quality.html I'm not aware of any stability problem. In my tests on different hardwares, the kernel driver is usually 20-40% faster because ntfs-3g is not optimized yet. In my opinion, the best would be, if the kernel driver were available too, so anybody could decide himself which driver to trust and use.
(In reply to comment #34) > > In my opinion, the best would be, if the kernel driver were available too, so > anybody could decide himself which driver to trust and use. > IMHO the very best would be if the 3G stuff would merge back into the kernel driver, so everyone would have full r/w support at full speed...
(In reply to comment #35) > IMHO the very best would be if the 3G stuff would merge back into the kernel > driver, so everyone would have full r/w support at full speed... Something like that is the long term plan of the upstream developers afaik, but it will take some time to get done.
> Something like that is the long term plan of the upstream developers > afaik, but it will take some time to get done. At present there are three developers and they are working on their own solution. 1. Anton Almaparmakov works closed source and plans the release a kernel driver not earlier than spring of 2008. 2. Yura Pakhuchiy works on ntfsmount, merging some of the ntfs-3g code and as he said "I implement things just for fun, no because anybody beside me wants them". 3. Szabolcs Szakacsits implemented recently full write support (he works on Linux NTFS support for almost 5 years), and being unsatisfied with the nature, quality and progress of the other two approaches, he established recently the NTFS-3G project and doesn't plan to port it to the kernel because of http://www.ntfs-3g.org/support.html#kernel Running a lot of complex code unpriviledged in user space with close to native kernel speed has some advantages. For example the recent NTFS kernel driver denial of service exploit at http://projects.info-pull.com/mokb/MOKB-19-11-2006.html doesn't work with ntfs-3g at all, and given that it worked, then it would have been a less serious, unpriviledged security compromise.
Fedora 7 test 4 still doens't have any ntfs support by default! And any ntfs partitions go unrecognised during anaconda install process! This is very sad when all other major linux distros have ntfs support resolved long time ago...
I believe ntfs-3g is available in default repos (Extras for fc =< 6).
If it is not on by default then it doesn't even count. What are you going to tell to your neighbor when she/he downloads this great thing called Fedora 7 that she/he heard about and when on installation it doesn't show data from his old system (ntfs)? Are you going to say to she/he: "I believe ntfs-3g is available in default repos (Extras for fc =< 6)." ?!? How many ms will she/hr think after you say that to her/him and convert Fedora CD/DVD to something much useful - like coaster :) Nope, until anaconda doesn't detect and support ntfs partitions by default this is a major issue Fedora has! Please look at Linux Mint and how they dealt with ntfs. It works automatically! And this is what most users need/want.
I asked for anaconda RFE so it mirrors ntfs support in fedora: https://bugzilla.redhat.com/show_bug.cgi?id=430087
ntfs-3g gets installed by default both in Fedora 8 and Fedora development. Look into http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/repodata/comps.xml http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Fedora/i386/os/repodata/Fedora-8-comps.xml In both cases ntfs-3g is enabled by default in "Base" group. Clicking on "Computer" in my GNOME desktop shows Windows Vista ntfs partitions. Can you reproduce this bug in a default installation of Fedora 8?
It works ok in both Fedora 8 and Rawhide.
Seems to be a bug in the current update of Fed20. when I install it I get a nonsense message that the update conflicts with itself, so it continues to attempt the update whenever I log on. Test Transaction Errors: file /usr/bin/ntfs-3g conflicts between attempted installs of ntfs-3g-2:2014.2.15-8.el6.x86_64 and ntfs-3g-2:2014.2.15-8.el6.x86_64 file /usr/bin/ntfsmount conflicts between attempted installs of ntfs-3g-2:2014.2.15-8.el6.x86_64 and ntfs-3g-2:2014.2.15-8.el6.x86_64
(In reply to olinart from comment #44) > Seems to be a bug in the current update of Fed20. when I install it I get a > nonsense message that the update conflicts with itself, so it continues to > attempt the update whenever I log on. > > Test Transaction Errors: file /usr/bin/ntfs-3g conflicts between attempted > installs of ntfs-3g-2:2014.2.15-8.el6.x86_64 and > ntfs-3g-2:2014.2.15-8.el6.x86_64 > file /usr/bin/ntfsmount conflicts between attempted installs of > ntfs-3g-2:2014.2.15-8.el6.x86_64 and ntfs-3g-2:2014.2.15-8.el6.x86_64 Man, I don't want to know why you're trying to install packages built for RHEL/Centos 6 (.el6) on Fedora 20, but I'm a little bit glad yum isn't letting you do that. I think you're doing something very wrong here, and you should take a very hard look at how you have that Fedora 20 system configured.