First off, I know the general advice is "Don't do that!". Don't use NTFS under Linux. Needless to say, we do it, because we need Windows interoperability (**). So, don't bother saying "Don't do that!".
Anyway, I've been doing a fair amount lately with NTFS (and also exFat, but that is another story) under RpiOS - and I got to wondering if/how well the Linux NTFS drivers support the more esoteric features of NTFS. That is, if I use Linux to copy a file, does it really make an exact copy of the file? Specifically, I'm wondering about NTFS "streams" (*). Does anyone know conclusively whether or not Linux drivers support this?
I suppose the only way to really test this would be to have a Windows machine and a Pi and 2 NTFS formatted volumes (say, 2 thumb drives). Load one of the volumes on the Windows machine and create a file with multiple streams. Then mount both of them on the Pi and copy the file from one to the other. Finally, load the second one on Windows and see if the multiple streams are there in the copied file.
Also, I'd be curious to know whether there is any way to access the named streams from Linux. What would be the notation?
(*) In case you are not familiar with the concept, NTFS supports essentially having multiple files wrapped up in a single file (***). Say you have a file called "foo". By default, there is just one stream - the unnamed stream - which contains the data as you would expect. However, you can also have another stream called, say, foo:bar - which is part of the file "foo", but contains an entirely separate stream of data (called the "bar" stream). Very few programs or people (users) use this functionality, but it is there nonetheless. At one point, I played around with it a bit - found it nifty, but not particularly useful. My understanding is that it is mostly used "internally" - that is, either by Windows itself or by utilities written by MS and supplied as part of Windows - that is, that it is not really intended for use by end users. I think Windows may use these streams to support/store "ACL"s. In some quarters, it is viewed as a mis-feature, since it can be (and apparently has been) used to conceal malware.
One thing I've often wondered about, but never got around to testing, is what happens if I write "a:foo"? Does that refer to a file called "foo" on the A: drive (a floppy drive) or does it refer to a stream named "foo" in a file named "a" ?
(**) And it seems a lot easier and safer to get NTFS functionality on Linux, than to get ext3/4 functionality on Windows. Yes, I know there are, in theory at least, drivers available for the later, but they don't pass the "sniff test" for me.
(***) Sorta like in the old days of MacOS (pre-OSX), where files had two forks - a "data fork", which contains the usual data and a "resource fork" that had additional stuff (meta data). This always caused an issue when you tried to use a non-Mac-native utility to copy the file.
Anyway, I've been doing a fair amount lately with NTFS (and also exFat, but that is another story) under RpiOS - and I got to wondering if/how well the Linux NTFS drivers support the more esoteric features of NTFS. That is, if I use Linux to copy a file, does it really make an exact copy of the file? Specifically, I'm wondering about NTFS "streams" (*). Does anyone know conclusively whether or not Linux drivers support this?
I suppose the only way to really test this would be to have a Windows machine and a Pi and 2 NTFS formatted volumes (say, 2 thumb drives). Load one of the volumes on the Windows machine and create a file with multiple streams. Then mount both of them on the Pi and copy the file from one to the other. Finally, load the second one on Windows and see if the multiple streams are there in the copied file.
Also, I'd be curious to know whether there is any way to access the named streams from Linux. What would be the notation?
(*) In case you are not familiar with the concept, NTFS supports essentially having multiple files wrapped up in a single file (***). Say you have a file called "foo". By default, there is just one stream - the unnamed stream - which contains the data as you would expect. However, you can also have another stream called, say, foo:bar - which is part of the file "foo", but contains an entirely separate stream of data (called the "bar" stream). Very few programs or people (users) use this functionality, but it is there nonetheless. At one point, I played around with it a bit - found it nifty, but not particularly useful. My understanding is that it is mostly used "internally" - that is, either by Windows itself or by utilities written by MS and supplied as part of Windows - that is, that it is not really intended for use by end users. I think Windows may use these streams to support/store "ACL"s. In some quarters, it is viewed as a mis-feature, since it can be (and apparently has been) used to conceal malware.
One thing I've often wondered about, but never got around to testing, is what happens if I write "a:foo"? Does that refer to a file called "foo" on the A: drive (a floppy drive) or does it refer to a stream named "foo" in a file named "a" ?
(**) And it seems a lot easier and safer to get NTFS functionality on Linux, than to get ext3/4 functionality on Windows. Yes, I know there are, in theory at least, drivers available for the later, but they don't pass the "sniff test" for me.
(***) Sorta like in the old days of MacOS (pre-OSX), where files had two forks - a "data fork", which contains the usual data and a "resource fork" that had additional stuff (meta data). This always caused an issue when you tried to use a non-Mac-native utility to copy the file.
Statistics: Posted by BigRedMailbox — Thu Dec 26, 2024 4:32 pm