On Tue, Jul 22, 2008 at 2:58 PM, Boris Epstein wrote:

On Tue, Jul 22, 2008 at 1:56 PM, Sharique uddin Ahmed Farooqui wrote:

...

Hi, How I can enable write support for users for ntfs partitions? I'm using opensuse 11.0. It was working fine in 10.3

-- Sharique uddin Ahmed Farooqui (C++/C# Developer, IT Consultant) http://safknw.blogspot.com/ "Peace" is the Ultimate thing we want. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

I am not 100% sure you can. I think - at least until recently - Linux only allowed you to mount NTFS partitions read-only, the reason being that M$ kept the specs proprietary.

ntfs-3g has been supported since 10.3. It provides full ntfs read/write. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Greg Freemyer wrote:

ntfs-3g has been supported since 10.3. It provides full ntfs read/write.

Greg

How stable and how fast is it? How well does it handle the esoteric NTFS stuff not in Linux -- like the access lists and such? Is this one of the drivers that runs MS-NTFS drivers in a compatibility mode? I was wondering -- MS supposedly opened up alot of their specs -- was NTFS one of them? Also -- I was wondering what people (if anyone) is thinking about doing for compatible filesystems for USB-thumb/flash drives? Wasn't there a 4G limit on FAT32?...or is that just XP creation? Still with a 32-bit FAT (1G), isn't it pretty much the case that the FAT's themselves need to be resident in memory all at once to maintain consistency? That sorta limits how big volumes might get. With a 32-bit FAT, all full, that would take what -- (assuming signed 32-bit integers, that's only 2-G blocks. I'm not sure what size blocks people are willing to go with -- but assuming an 8-K block size, we're still limiting volume sizes to 16-terabytes -- WITH a 2G FAT table -- which would be huge -- if not entirely impractical in practice. Just *guessing*, but anything more than maybe 8-16M of FAT table would be stretching FAT, using that as a limiting factor, that constraings FAT volumes to 8K(8M-16M)=64G-128G, which is still 3-4 years away for mem drives (8G chips were available for cameras a year ago...so doubling every every year would be 64G in 2, every 18 months=3 years. But main prob with FAT32 is the 2G file-size limitation. I started hitting that 2-4 years ago, at least. The other problems -- that large FAT size that ideally needs to fit in memory, might be redone to allow partial mappings -- but I think the device would need to be locked while a process is updating the FAT map -- certainly not ideal. I know there are plenty of file systems on linux -- but virtually none of them are ported to Win32, and I can't see NTFS becoming a defacto-industry standard as long as MS sits on it as proprietary. Already, on newer electronics w/cheap ROM's (phones), some are limited to using 4G chips because of addressability problems. Perhaps ideally, such a file system would get input from flash-ram designers to optimize file system operations with what's optimal for HW now -- and is likely to be optimal in the future. Anyone thinking about this stuff? linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, 23 Jul 2008 08:45:49 Rodney Baker wrote:

...

[...]

I know there are plenty of file systems on linux -- but virtually none of them are ported to Win32, and I can't see NTFS becoming a defacto-industry standard as long as MS sits on it as proprietary.

There is a stable ext3 installable file system (IFS) driver which allows you to mount ext3 partitions natively on XP. I have that on my laptop as well to provide two-way data access (i.e. access Linux partitions from XP with ext3.ifs and XP data from Linux with ntfs-3tg). It also provides write access and appears to be safe; I've mainly used it for read access to the Linux partitions but on the occasions that I've had to write from XP to Linux it hasn't caused any problem. YMMV.

I should also say that ext2.ifs (I incorrectly called it ext3.ifs above but it does not support journalling) could be a security risk in a secure environment as it does not preserve permissions as set on the ext 2/3 file system - if a driver letter is created for a Linux partition in Windows, all local Windows users have read/write access to that drive. In other words, your Linux root partition can become globally readable/writeable for Windows users (you can figure out the implications of that). Therefore I only use it on systems that only I have access to and I don't map the / partition to a drive letter on Windows (unless absolutely necessary, which is almost never...). -- =================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au =================================================== Flappity, floppity, flip The mouse on the m"obius strip; The strip revolved, The mouse dissolved In a chronodimensional skip.

On Tue, Jul 22, 2008 at 6:58 PM, Linda Walsh wrote:

Greg Freemyer wrote:

...

ntfs-3g has been supported since 10.3. It provides full ntfs read/write.

Greg

---- How stable and how fast is it?

How well does it handle the esoteric NTFS stuff not in Linux -- like the access lists and such?

Access Lists are in Linux!!!! They just have different values. man -k acl shows you a few linux tools to work with them. And smbcacls is part of Samba and allows you to work with NTFS acls. (I've never used it.)

Is this one of the drivers that runs MS-NTFS drivers in a compatibility mode?

Don't think so.

I was wondering -- MS supposedly opened up alot of their specs -- was NTFS one of them?

Also -- I was wondering what people (if anyone) is thinking about doing for compatible filesystems for USB-thumb/flash drives?

Wasn't there a 4G limit on FAT32?...or is that just XP creation?

file limit, yes. filesystem limit is 32GB in XP I think. I have done 750GB in Linux with mkfs.vfat.

Still with a 32-bit FAT (1G), isn't it pretty much the case that the FAT's themselves need to be resident in memory all at once to maintain consistency? That sorta limits how big volumes might get.

Don't think so. I have not noticed our large drives being particularly slow.

With a 32-bit FAT, all full, that would take what -- (assuming signed 32-bit integers, that's only 2-G blocks. I'm not sure what size blocks people are willing to go with -- but assuming an 8-K block size, we're still limiting volume sizes to 16-terabytes -- WITH a 2G FAT table -- which would be huge -- if not entirely impractical in practice. Just *guessing*, but anything more than maybe 8-16M of FAT table would be stretching FAT, using that as a limiting factor, that constraings FAT volumes to 8K(8M-16M)=64G-128G, which is still 3-4 years away for mem drives (8G chips were available for cameras a year ago...so doubling every every year would be 64G in 2, every 18 months=3 years.

But main prob with FAT32 is the 2G file-size limitation. I started hitting that 2-4 years ago, at least. The other problems -- that large FAT size that ideally needs to fit in memory, might be redone to allow partial mappings -- but I think the device would need to be locked while a process is updating the FAT map -- certainly not ideal.

Processes don't update FAT tables in general. The kernel FS driver does that. And I'm sure they have it down pat by now.

I know there are plenty of file systems on linux -- but virtually none of them are ported to Win32, and I can't see NTFS becoming a defacto-industry standard as long as MS sits on it as proprietary.

We still use FAT as our open standard. With big files we break them apart via split. Re-assemble with cat. Our industry (Computer Forenisics) actually has lots of tools that work with the split files since the need to so great.

Already, on newer electronics w/cheap ROM's (phones), some are limited to using 4G chips because of addressability problems. Perhaps ideally, such a file system would get input from flash-ram designers to optimize file system operations with what's optimal for HW now -- and is likely to be optimal in the future.

Anyone thinking about this stuff?

linda

-- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tue, Jul 22, 2008 at 9:03 PM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Tuesday 2008-07-22 at 19:33 -0400, Greg Freemyer wrote:

...

...

the FAT's themselves need to be resident in memory all at once to maintain consistency? That sorta limits how big volumes might get.

Don't think so. I have not noticed our large drives being particularly slow.

http://en.wikipedia.org/wiki/File_allocation_table#FAT32

] Windows 2000 and Windows XP can read and write to FAT32 file systems of ] any size, but the format program included in Windows 2000 and higher ] can only create FAT32 file systems of 32 GB or less. This limitation is ] by design and according to Microsoft was imposed because many tasks on ] a very large FAT32 file system become slow and inefficient.[12][16] ] This limitation can be bypassed by using third-party formatting ] utilities or by using the built-in FORMAT.EXE command-line ] utility.[17][18]

...

...

We still use FAT as our open standard. With big files we break them apart via split. Re-assemble with cat.

Our industry (Computer Forenisics) actually has lots of tools that work with the split files since the need to so great.

Now, I wonder why the 4 GiB file size limit. The wikipedia says:

] The maximum possible size for a file on a FAT32 volume is 4 GB minus 1 ] "null" byte (232−1 bytes). Video applications, large databases, and ] some other software easily exceed this limit. Larger files require ] another formatting type such as HFS+ or NTFS. Until mid-2006, those who ] run dual boot systems or who move external data drives between ] computers with different operating systems had little choice but to ] stick with FAT32. Since then, full support for NTFS has become ] available in Linux and many other operating systems, by installing the ] FUSE library (on Linux) together with the NTFS-3G driver. Data exchange ] is also possible between Windows and Linux by using the Linux-native ] ext2 or ext3 file systems through the use of external drivers for ] Windows, such as ext2 IFS; however, Windows cannot boot from ext2 or ] ext3 partitions.

But just now I can't think what's the technical reason for this limit :-?

If it were a cluster count limit (per file), the size limit would vary with cluster size...

There is an exFAT format that allows 2^64 bytes per file. I didn't know of that filesystem.

http://en.wikipedia.org/wiki/ExFAT

- -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFIhoN6tTMYHG2NR9URArbZAJ43MZtDgSXeyNPn/fOu6bxXL8oUHwCfW0w4 kUdwdXS9sR8JRvVMh5w8OqU= =7dV7 -----END PGP SIGNATURE-----

Didn't OpenSuse11 change one of the properties of ext3 so that now it can't be mounted under Windows using the available tools? I think it was 256byte inodes or something like that, I'm not an expert on filesystems... Also, are there any programs under development that will allow ext4 access from Windows? (I realized ext4 itself is still under development). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Greg Freemyer wrote:

...

...

ntfs-3g has been supported since 10.3. It provides full ntfs read/write.

How stable and how fast is it?

How well does it handle the esoteric NTFS stuff not in Linux -- like the access lists and such?

Access Lists are in Linux!!!! They just have different values.

Exactly. Sorry, wasn't clear -- am aware of linux access lists, but not only are the semantics different (oddly 'NT'), but I was interested in cross compatible file-formats between NTFS and Linux so I could use linux tools, for example to backup and restore NTFS filesystems. Backups on Win into a dump or tar format would be nice -- but with tar, for example, I don't think it would restore all the XP ACL's and modes -- not to mention NTFS's alternate data streams. AFAIK, only 'xfs' supports any alternate data stream -- and it's is fairly limited if I remember (limited size: 256K?, dunno if per/entry or total, values are stored something like 'environment' vars (name=value)). While useful for storing limited ACL stuff, not sure about general usefulness).

man -k acl shows you a few linux tools to work with them.

Yeah -- I keep meaning to play w/them, but something that "irks me" -- if I compile a kernel w/acls, then sometime later run a kernel w/o ACL support, aren't the access lists ignored? I.e. not only would the lists get ignored -- but any copying and restoring by "ignorant utils" and the lists might just 'disappear' -- even if I'm on a kernel with ACL support. It may be a non-issue, but I look at NTFS, and think that it wouldn't be likely to boot up a version of NT w/o ACL support. OTOH, I don't know how the linux NTFS driver respects or deals with ACL's, so it may be a similar problem -- which could make a dual boot machine an easy way to get around an ACL lists.

...

Wasn't there a 4G limit on FAT32?...or is that just XP creation?

file limit, yes. filesystem limit is 32GB in XP I think. I have done 750GB in Linux with mkfs.vfat.

Yeah -- 32GB -- that sounds familiar (been a while since I created a FAT32 on XP). The linux FAT utils are sweet, but I have made FAT partitions on linux that XP refused to recognize...never was quite sure why -- all the params seemed to be "within reason"...(kept allocation units <64K, for example, FAT was under 256K in mem)... Wasn't so important for what I needed at the time...I think I was trying for the minimum file entries in the root dir & 1 FAT (was going to put the pagefile on it).

...

Still with a 32-bit FAT (1G), isn't it pretty much the case that the FAT's themselves need to be resident in memory all at once to maintain consistency? That sorta limits how big volumes might get.

Don't think so. I have not noticed our large drives being particularly slow.

That doesn't surprise me -- I'd expect linux to fix that before windows and make it faster.

Processes don't update FAT tables in general. The kernel FS driver does that. And I'm sure they have it down pat by now.

Yeah -- for sake of integrity, probably sufficient to limit to single writers/readers. Was just thinking of multi-processing cases where one file is writing/updating the FAT, but another might be reading -- and could get inconsistent values if the reader read the FAT table in the middle of an update -- seems like that could cause some unpredictability -- but is easily avoided if you only allow exclusive access if someone wants to write it.

...

I know there are plenty of file systems on linux -- but virtually none of them are ported to Win32, and I can't see NTFS becoming a defacto-industry standard as long as MS sits on it as proprietary.

We still use FAT as our open standard. With big files we break them apart via split. Re-assemble with cat.

--- Yeah -- a pain -- especially if copying a large file -- someone else claimed a 4G FAT limit, but I know I hit limits at 2G more than once. So I'm fairly sure that above 2G isn't real "safe" or "portable" -- might have been the 32-bit software accessing the file -- its been a while since I ran into it w/FAT (cause I switched to NTFS on Win because of the large file prob).

Our industry (Computer Forenisics) actually has lots of tools that work with the split files since the need to so great.

I'm sure -- but for user-level software -- and cygwin, I can't see them automatically supporting files >2GB if the OS doesn't natively support it. Been a while. As far as I know, EXT3 wouldn't be a good choice for removable disks because the journaling would cause excess wear -- and I don't think that all flashrams have 'nearly unlimited' (from a user perspective, not in an absolute sense) read/write cycle capacity...residual capacitance charge? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tuesday 22 July 2008 09:29:29 am Greg Freemyer wrote:

On Tue, Jul 22, 2008 at 2:58 PM, Boris Epstein wrote:

...

On Tue, Jul 22, 2008 at 1:56 PM, Sharique uddin Ahmed Farooqui

wrote:

...

Hi, How I can enable write support for users for ntfs partitions? I'm using opensuse 11.0. It was working fine in 10.3

-- Sharique uddin Ahmed Farooqui (C++/C# Developer, IT Consultant) http://safknw.blogspot.com/ "Peace" is the Ultimate thing we want. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

I am not 100% sure you can. I think - at least until recently - Linux only allowed you to mount NTFS partitions read-only, the reason being that M$ kept the specs proprietary.

ntfs-3g has been supported since 10.3. It provides full ntfs read/write.

Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com

It seems that "write" priviledges in ntfs-3g default to root only. You probably have to run the chmod command as root, then you can access ntfs as a mere mortal:) d. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org