uninstall command

Hi there,

I've been trying to uninstall NTFS-3G on my PowerMac G5 with no success. I'm running the current version of
Leopard (10.5.2) and the uninstall command provided doesn't work.
It works fine in Tiger (10.4.11) with no issues whatsoever.
I would appreciate any help to remove NTFS-3G from this machine.
I have no experience using the terminal so my experience is very limited in this sort of thing.

Thank you,
Niko
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: source code adjustments for error handling

On Thu, 28 Feb 2008, SF Markus Elfring wrote:
> > If Szaka would not have given error handling very high priority
> > ntfs-3g would not work as well as it does.
> 
> I guess that there are a few places left for fine-tuning in the software
> infrastructure.

There are a few places, and Szaka already gave you a suggesiton on how
to improve logging for example.

I reviewed your patch and did not find a single change which I would
take on board because (at least among free software authors, there is
a tradition to demand that code has to be right to be merged).

Saka gave you directions to improve it, and I would not take it either
as it is because it clutters the code with statements which should be
put into a logging library and not into the main code stream.

The string changes appear also bad to me because they may not even be
an improvement overall and can lead to bugs itself because these changes
may change the value of sizeof() on these strings. For further info, please
read this thread from the Linux Kernel ML: http://lkml.org/lkml/2005/6/21/16

Also, to make reviewing patches easyer, they should be splitted up in
one patch per addressed issue, e.g. fixes for different warning types
should not be mixed into one patch if it extends over several pages.

Besides I want to say a word on the functions for which adding return
code checks is sensible: I do not agree on adding extra code to the
program binary to check which exists the program on a condition like

Re: source code adjustments for strings

> See objdump(1), size(1), etc.

My update suggestion for array variables belongs to the open issue "cleanup patches for strings".
http://lkml.org/lkml/2005/6/21/16
http://kernelnewbies.org/KernelJanitors/Todo

Regards,
Markus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: source code adjustments for strings

On Tue, 4 Mar 2008, SF Markus Elfring wrote:
> > See objdump(1), size(1), etc.
> 
> My update suggestion for array variables belongs to the open issue "cleanup patches for strings".
> http://lkml.org/lkml/2005/6/21/16

Suggestions are not always helpful, there are more important ares to work on:

As I just mentioned, the discussion which I referred before and which you now link to
is not conclusive. It may depend on the platform what is better. On x86_64, it seems
it saves two bytes per use of the string in the assembly but you would have to check
that nobody does sizeof() of that string because that value changes with your changes.

In any case it's not significant in the case of ntfs-3g as these strings are
not printed at a significant number of places. With -O2 and stripped, the
difference goes near zero.

If you cleanup your patch to only contain the string changes, I would be able to do
do a comparsion on the final binary size and in addition, we'd need a script (maybe
grep with context using -B 2 is sufficient) to check whether any sizeof() is taken
anywere. You would need to check that.

> http://kernelnewbies.org/KernelJanitors/Todo

That page is sadly not informative enough of the issue. If omits the possible
problem of sizeof() possibly being used on the string and the patch
submitted in the lkml thread above was not merged into the kernel.

	Bernhard

Re: source code adjustments for error handling

> This can be done by estabilishing the use of
> 	__attribute__ ((__warn_unused_result__))
> (a GCC extension which can be used when gcc is used for compilation)
> to generate warnings if the return values of critical functions
> are not checked. I'll submit a patch (for demonsration only)
> in this regard in a few moments.

I am curious on your approach.

I assume that some configuration macros might be required for such compiler-specific extensions.
http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Function-Attributes.html

How often was the option "ENABLE_MUST_CHECK" activated for Linux kernel compilation already?
http://kernelnewbies.org/KernelJanitors/Todo/ReturnCodes

Regards,
Markus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: source code adjustments for strings

> That page is sadly not informative enough of the issue. If omits the possible
> problem of sizeof() possibly being used on the string and the patch
> submitted in the lkml thread above was not merged into the kernel.

Experienced C programmers will know the difference between sizeof() on pointers/arrays and strlen() on strings.
Will this clean-up detail get a ticket or bug number for further reference?

Regards,
Markus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[PATCH] For review: Fix for crash if $INDEX_ROOT is not found

Bonjour Jean-Pierre,

 I started playing around with your latest NTFS-3G release with support
for file ownership and permissions from

	http://pagesperso-orange.fr/b.andre/security.html

	http://pagesperso-orange.fr/b.andre/ntfs-3g-1.2129SR.1.tgz

and started off with an already used NTFS volume which I created using mkntfs
from ntfsprogs. I saw warnings of ntfs-3g not findig $Secure and after creating
it by hand as a normal file, I tried

	vim /ntfs/.NTFS-3G/UserMapping

and got a crash. The cause seems to have been that it also appears to need
$INDEX_ROOT which it also didn't find until I created it by with touch.
I Started ntfs-3g in the debugger and saw that the cause was that

		xsdh->entry

as returned by was zero ntfs_index_lookup() and it was deferenced without
further check before dereferencing it.

I only assume that missing $INDEX_ROOT played a role in this crash because
it was the error message which ntfs_index_lookup() printed before returning
the zero xsdh->entry.

I saw that ntfs_index_lookup() does not touch xsdh->entry if the lookup
fails, so I added a check to abort the function in that case. Please find

Re: source code adjustments for error handling

On Tue, 4 Mar 2008, SF Markus Elfring wrote:
> 
> > This can be done by estabilishing the use of
> > 	__attribute__ ((__warn_unused_result__))
> 
> I am curious on your approach.

Thanks for the reminder. Now, it went over the list - a few minutes ago.

> I assume that some configuration macros might be required for such compiler-specific extensions.
> http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Function-Attributes.html

That documentation page at least does not seem to say so.

My approach uses a macro which checks for gcc and its
version before enabling it. Maybe that was whay you ment.

For example glib's /usr/include/sys/cdefs.h enables its use simply
depending on the gcc version and the kernel seems to do so too if
ENABLE_MUST_CHECK is turned on.

> How often was the option "ENABLE_MUST_CHECK" activated for Linux kernel compilation already?
> http://kernelnewbies.org/KernelJanitors/Todo/ReturnCodes

AFAICS, it's enabled in most default configs.

Why is that relevant to ntfs-3g when __attribute__ ((__warn_unused_result__))
is already under heavvy use in glibc (inside a gcc version check) already?

	Bernhard

Bug with amd64 on VMWare

Good evening,

I am one of the developers responsible for getting Wubi, the Windows
Ubuntu Installer, properly integrated into Ubuntu.  For those of you who
are not familiar with the project, Wubi lets a user install Linux inside
Windows by creating a loopback ext3 filesystem on the Windows NTFS
partition.

In testing this I believe I've uncovered a bug in ntfs-3g.  I can
trigger this bug reliably by doing an install using the amd64 version of
Wubi and Ubuntu on VMWare, but user testing seems to indicate that this
does not effect amd64 on bare metal.  The install itself completes
without issue, but upon rebooting ntfs-3g bails out, producing the
attached log file.

Any help or suggestions will be much appreciated.

We are using ntfs-3g 1.1120.  If you think this may be fixed in the
latest version, I can work to get that in the Ubuntu archive.

Thanks,
Evan Dandrea

Press any key to continue.

Press any key to continue.

Press any key to continue.

Press any key to continue.

Press any key to continue.

Press any key to continue.

Re: [PATCH] For review: Fix for crash if $INDEX_ROOT is not found

Hi, Bernhard

> Message du 04/03/08 21:47
> De : "Bernhard Kaindl" <bk <at> suse.de>
> A : "Jean-Pierre André" <jpandre <at> users.sourceforge.net>
> Copie à : ntfs-3g-devel <at> lists.sourceforge.net
> Objet : [ntfs-3g-devel] [PATCH] For review: Fix for crash if $INDEX_ROOT is  not found
> 
> Bonjour Jean-Pierre,
> 
>  I started playing around with your latest NTFS-3G release with support
> for file ownership and permissions from
> 
>       http://pagesperso-orange.fr/b.andre/security.html
> 
>       http://pagesperso-orange.fr/b.andre/ntfs-3g-1.2129SR.1.tgz
> 
> and started off with an already used NTFS volume which I created using mkntfs
> from ntfsprogs. I saw warnings of ntfs-3g not findig $Secure and after creating
> it by hand as a normal file, I tried

Which NTFS format version was built by mkntfs ?

This information is written to the system log, in the following
example it is 3.1

Version 1.2216SR.1 integrated FUSE 27
Mounted /dev/sdb1 (Read-Write, label "ntfs-try", NTFS 3.1)
Cmdline options: rw,nosuid,nodev,uhelper=hal,locale=en_US.UTF-8