Jack// ani wrote:

> My machine is running WindowsXP and Mandrake10.1. I can read the
> contents of windows partition in linux, but cannot write to it! When I
> try to move or delete any file I get an error. How can I make the

there are tools that can write to it, but i wouldnt recommend it.
writing to ntfs is experimental at best. use a fat32 partiton
for sharing between boots

Hi there,

My machine is running WindowsXP and Mandrake10.1. I can read the
contents of windows partition in linux, but cannot write to it! When I
try to move or delete any file I get an error. How can I make the
things go right?

Thanks.

On 2005-02-11, Jack// ani <nospam4u_jack> wrote:
> contents of windows partition in linux, but cannot write to it!

Support for writing on NTFS is experimental and not recommended.
If you really want to do it, you'll have to enabled it in the
kernel. If you do so, and you end up with a completely hoosed
partition, is your problem so don't came here to cry.

Davide

On 11 Feb 2005 10:06:55 -0800, Jack// ani wrote:
> Hi there,
>
> My machine is running WindowsXP and Mandrake10.1. I can read the
> contents of windows partition in linux, but cannot write to it! When I
> try to move or delete any file I get an error. How can I make the
> things go right?

Create a fat 32 partition using M$ disk utilities.
Then on linux
mkdir/mnt/mnt_d
Add this line to /etc/fstab
/dev/hda5 /mnt/win_d vfat umask=0,iocharset=iso8859-1,codepage=850 0 0

and test with
mount /mnt/win_d
touch /mnt/win_d
rm /mnt/win_d


Of course this assums hda5 is the partition where you created the
fat32 partition under doze.


If the above is not what you want

Please bookmark the following, very large,
Frequently Asked Questions (faq) Search engine:

http://groups.google.co.uk/advanced_group_search
write NTFS in the first box
*mandrake in Newsgroup box.

Results 1 - 10 of about 1,480 English messages for write NTFS
group:*mandrake. (0.53 seconds)

If you want/need more control over the first box search,
http://www.google.com/help/refinesearch.html

Ok fine thanks for all replies. I have plenty of space left on my /
partition, I'm wondering if it is possible to convert the unused space
into fat32 without loosing any data.

Jack// ani <nospam4u_jack> wrote:
> Ok fine thanks for all replies. I have plenty of space left on my /
> partition, I'm wondering if it is possible to convert the unused space
> into fat32 without loosing any data.

What's to wonder? Shrink the root partition (you would normally have /,
/usr, /home, /var, /tmp etc. partitions), and make a fat32 partition in
the new free space.

You'll have to use a live cd as temporary root while you make the
changes.


Peter

"Peter T. Breuer" <ptb> wrote in message
news:5ln1
> Jack// ani <nospam4u_jack> wrote:
>> Ok fine thanks for all replies. I have plenty of space left on my /
>> partition, I'm wondering if it is possible to convert the unused space
>> into fat32 without loosing any data.
>
> What's to wonder? Shrink the root partition (you would normally have /,
> /usr, /home, /var, /tmp etc. partitions), and make a fat32 partition in
> the new free space.
>
> You'll have to use a live cd as temporary root while you make the
> changes.

And Peter once again spouts off and gets it wrong.

#1: Overpartitioning makes it difficult if not impossible to juggle space
for other uses, since each partition needs spare space for surprises and
it's difficult to share them. Don't use so many partitions or you'll go nuts
trying to scrape space away for exactly this sort of usage. Peter is a
proponent of making many, many partitions. His belief is fundamentally
mistaken, for exactly the sort of reasons you are cncountering now.

#2: There are tools like "parted" for shrinking partitions, and most modern
installation media and live CD's have these tools. But they need to be used
cautiously, and preferably with the system backed up first, just in case
bugs have crept in. For example, the SuSE 9.1 media had a 2.4 kernel based
parted command, but a 2.6 kernel: it caused endless grief with certain
resizing operations if your disk happened to be over 1024 cylinders,
typically 8 Gig. And if you re-arrange the /boot partition on SuSE,
grub-install is apparently deliberately broken and its operations welded
into YaST, but extremely badly, so you can easily make your system
unbootable.

Normally these days, I would add another disk. Modest size disks are quite
inexpensive, and you don't have to risk your active OS to add them. But if
you need to re-partition, use a very recent version of a good quality OS. I
find Fedora Core 3 installation or rescue disks, for example, to be very
useful for disk recovery operations.

The one year old message quoted below is from Rick Moen who is very
knowledgable about NTFS suppport on Linux:

This is no longer the case, even though it's long been accepted wisdom,
and is something you will routinely hear.

As many people know, there have been two Linux kernelspace drivers for
NTFS, which I'll refer to as old and new. The old driver (_not_
written
by the current Linux-NTFS team) rather naively failed to check the NTFS
version string, in the apparent belief that Microsoft would never
change
the format. Worse, the original authors stopped maintaining that code
some time before Microsoft, indeed, changed NTFS's internal structures,
post-NT4 -- twice, once for Win2k, and then again for XP/Win2003.

The results were predictable: People used the old, recklessly
incautious driver on post-NT4-created NTFS filesystems, resulting in
corruption. This situation persisted for several years (because the
old driver was no longer being maintained), during which many people
including me got the idea firmly fixed in our heads that "the Linux
NTFS
driver's write mode is dangerous". Which was never quite accurate.

Also, further things have changed: The new Linux-NTFS team have
retrofitted safeguards into the old driver, so that it now refuses
all attempts to coax it to write to post-NT4-format filesystems.

The _new_ driver is a from-scratch reimplementation to get away from
those and other problems. (For example, the new driver is SMP-safe;
the old one never was.) Initially, it included no write-mode code
whatsoever. It now has limited write support. (Details are on
http://linux-ntfs.sourceforge.net/status.html .)

(It's important to speak of both drivers because they're both still in
use.)

Nico Kadel-Garcia wrote:
> "Peter T. Breuer" <ptb> wrote in message
> news:5ln1
>>
> And Peter once again spouts off and gets it wrong.
>
> #1: Overpartitioning makes it difficult if not impossible to juggle space
> for other uses, since each partition needs spare space for surprises and
> it's difficult to share them. Don't use so many partitions or you'll go nuts
> trying to scrape space away for exactly this sort of usage. Peter is a
> proponent of making many, many partitions. His belief is fundamentally
> mistaken, for exactly the sort of reasons you are cncountering now.

You continue to spread FUD about partitioning, and encouraging people to
put everything in a single partition, allowing every problem to be a
potential disaster. Since Linux lacks the ability to restrict disk using
in a hierarchy by any stable means other than partitions, in many cases
they are appropriate.

You have made your choice, kindly take the "anyone who disagrees with me
is wrong" attitude away. The correct number of partitions varies with
the intended use, there are times when just one is good, there are times
when it isn't. One size doesn't fit all.

"Bill Davidsen" <davidsen> wrote in message
news:6189

> You continue to spread FUD about partitioning, and encouraging people to
> put everything in a single partition, allowing every problem to be a
> potential disaster. Since Linux lacks the ability to restrict disk using
> in a hierarchy by any stable means other than partitions, in many cases
> they are appropriate.

No FUD, I've been dealing with the debris of over-partitioning and its
kissing cousing, mis-partitioning, for years. Keeping your partition
structures simple and uniform is more likely to prevent your system from
thrashing than forking off partitions. Let's look at some examples.

/ (used to be wienie for bootstrap installation reasons, now can hold
anythng)
/tmp (winds up with huge temporary files from certain HTTP download
tools)
/var/tmp (holds various large software bundles during RPM construction)
/usr/tmp (usually symlinked to one of the above)
/home (can actually make sense to separate, if you can predict how much
space is maximally allowed)
/usr
/usr/local (may grow wildly with installation of bulky open source
packages, such as gcc)
/usr/src (used for package building, such as RPM's. Can grow wildly
in the process)
/var
/var/log (often restricted, but when you turn up logging or get
slashdotted, tends to explode in size)
/var/spool (can make sense to partition, particularly if turning off
noatime for news spool usage or if using reiserfs for better journaling on a
system that does not yet support ext3 with Htrees).
/opt (commercial package locations, size varies wildly with installation
of Mozilla, GNOME, or Oracle)

Now, for a person who likes to partition a lot and finds what they're doing
changes with new projects, what will we run into? Compilation and other
failures as partitions overload on a frequent basis, and whining as they
have to back up and properly re-partition their systems all the time. Even
the same software can change location over time, requiring different default
locations. (Mailman on RedHat was horrid for this, as it went from /usr to
/home to /var)

What do we get with minimal partitioning? All the free space is usable to
all the different projects when they occur, rather than having to
re-partition.

> You have made your choice, kindly take the "anyone who disagrees with me
> is wrong" attitude away. The correct number of partitions varies with the
> intended use, there are times when just one is good, there are times when
> it isn't. One size doesn't fit all.

That's true. But the history of the "gotta get everything off of /" goes
back to the days when operating systems had to be boot-strapped from tape
and the first partition had a maximum size of only a few Megabytes, and disk
was expensive. With the cheapness of disk right now, and the discarding of
the backup tools such as "dump" that could only properly dump a partition,
not a directory, there's no excuse for most of it. It's a learned habit that
should be unlearned.

There are times to partition: when your space requirements won't fit on one
disk, or when you want to set up one filesystem with an optimized setting
for maximum performance, for example, certainly. But for general use it's a
complete waste of the programmer's time.

In comp.os.linux.setup Nico Kadel-Garcia <nkadel>:

> "Bill Davidsen" <davidsen> wrote in message
> news:6189

>> You continue to spread FUD about partitioning, and encouraging people to
>> put everything in a single partition, allowing every problem to be a
>> potential disaster. Since Linux lacks the ability to restrict disk using
>> in a hierarchy by any stable means other than partitions, in many cases
>> they are appropriate.

> No FUD, I've been dealing with the debris of over-partitioning and its
> kissing cousing, mis-partitioning, for years. Keeping your partition
> structures simple and uniform is more likely to prevent your system from
> thrashing than forking off partitions. Let's look at some examples.

Let's use some example that shouldn't be that rare, assume you
have a laptop with a shrink-ed NTFS partition (eXPensive + some
Linux distro) on it, if I follow your advice I have only three
(ntfs/swap/root) partition on the laptop. Now I'd like to install
another distro, say Debian, and peng one needs to resize
partitions again.;(

Following best practice in >30 years of unix with multiple
partitions, one could easily use /home or so of your first Linux
installation, move the stuff and make an extended partition out
of the space and put a few partitions in it, for the new distro,
sharing a new /home with the already installed distro would be
possible saving lots of space. So no resizing of partitions
needed as with your approach you try to sell to people. IMHO
multiple partition give you much more flexibility, sure one of
the reasons it's best practice and recommended by major *nix
vendor since decades.

[..]

"Michael Heiming" <michael+USENET> wrote in message
news:hln1
> In comp.os.linux.setup Nico Kadel-Garcia <nkadel>:
>>
>
> Let's use some example that shouldn't be that rare, assume you
> have a laptop with a shrink-ed NTFS partition (eXPensive + some
> Linux distro) on it, if I follow your advice I have only three
> (ntfs/swap/root) partition on the laptop. Now I'd like to install
> another distro, say Debian, and peng one needs to resize
> partitions again.;(

OK, good point. Or you'd need to add an external drive. Do you have the
space to install wienie partitions?

> Following best practice in >30 years of unix with multiple
> partitions, one could easily use /home or so of your first Linux
> installation, move the stuff and make an extended partition out
> of the space and put a few partitions in it, for the new distro,
> sharing a new /home with the already installed distro would be
> possible saving lots of space. So no resizing of partitions
> needed as with your approach you try to sell to people. IMHO
> multiple partition give you much more flexibility, sure one of
> the reasons it's best practice and recommended by major *nix
> vendor since decades.

This can actually work, as long as you haven't over-partitioned and stripped
down the available space for /home due to allocating space for /usr/src,
/usr/local/, /var/tmp, /var/tmp, /var/spool, /etc., etc., etc.. In the last
5 years, I've done this *once*, with someone who really liked having really
old (for speed) distros along with really new (for performance) distros.
There are some potential issues.

#1. Not all distros create compatible file systems, even the same type of
file system. The 7.x RedHat release, for example, used a mkfs that made the
ext2 partitions unreadable to 6.x. I ran headlong into that one: you had to
use the mkfs binary from RedHat 6.x

#2: You probably want to keep the entirety of both file systems available to
the other OS installations. Let's say that "/" from one OS becomes "/diska/"
when mounted on the other, and "/" from the other becomes "/diskb" when
mounted on the first. If you leave the /home still as part of the first OS
and mounted there, it can be accessed by a symlink to /home -> /diska/home.
Workable, but graceless.

#3: HOWEVER! Different OS's often have rather different ideas about user
configuration files, and therein lies the rub of maintaining the identical
user account across multiple OS's. The associated .X configuration files,
..gnome, .mozilla, etc. can and do interfere with each other. I've seen
systems destabilize wildly because the .cshrc written for one system caused
utter chaos when implemented on the other. (Admittedly, it was a terrible
..cshrc, but still, it wasted quite a lot of my time getting the person to
let me fix it for them.) So that's actually a reason *against* sharing
/home's between OS's, even on the same laptop.

In such a situation, I can certainly see using a shared partition. But I
wouldn't make it /home.