(old)Puppy Linux Discussion Forum

not at a puppy machine at the memoent so I can't check.

Yesterday I attempted to unzip a wireless drivers .exe file and got all sorts of errors. At first I thought maybe it was becuase the exe wasn't a self extracting archice and that's why unzip was having trouble (even though it listed the contents porperly), then I realized to my horror that I was trying to nzip straight into the NTFS drive where the drivers were stored.

I moved it to ~ and was able to keep working, it was only later that I wondered if the errors in unzip were due to itthinking the mount was writable nad failing to write, or if it's just hte normal behavior for unzip if the mount is read-only.

Anyway, if they're not, NTFS partitions should be mounted as read-only to avoid any inadvertent writing/corrupting.

I don't think NTFS is mounted as read-only, IF you are using pup001 on NTFS as your home

both /dev/hda1 and pup001 mounted as full read-write

don't know pup001 could be writable if /dev/hda1 is in read-only

only workaround is to hide /dev/hda1 by deleting it from mtab/fstab, df won't show the entry anymore. but pup001 should be still functional as usual

papaschtroumpf wrote: Anyway, if they're not, NTFS partitions should be mounted as read-only to avoid any inadvertent writing/corrupting.

drj wrote:don't know pup001 could be writable if /dev/hda1 is in read-only

hadn't thought about that. don't know the answer either since I'm not sure how the mounting of pup001 occurs.
Of course in my case pup001 is on /dev/sda1 so it wouldn't be an issue to lock the NTFS partition.

drj wrote:only workaround is to hide /dev/hda1 by deleting it from mtab/fstab, df won't show the entry anymore. but pup001 should be still functional as usual

but then you don't have read access to the NTFS partition either.

As long as puppy cannot write to NTFS I don't mind weird error messages. I'm just worried if puppy could attempt to write if the user forgets he's on the NTFS partition like I did and corrupt the NTFS filesystem.

See here.