Jun 06, 2018 From interoperable to embedded Tuxera Flash File System is not the first Tuxera storage software product to support INTEGRITY RTOS. Previously, the two companies have worked together adding INTEGRITY RTOS support to a wide selection of Tuxera’s external storage file system implementations, including Tuxera exFAT, Tuxera NTFS, and Tuxera FAT.

Tuxera Ntfs Embedded File

Tunear Ntfs Torrent

View unanswered posts | View active topics

It is currently Sat Apr 11, 2020 11:37

NTFS-3G POSIX namespace incompatible with some embedded hw.

Moderators: d242, szaka

Page 1 of 1

[ 7 posts ]

Previous topic | Next topic

NTFS-3G POSIX namespace incompatible with some embedded hw.

Author	Message
NTFS-3G POSIX namespace incompatible with some embedded hw. I have a USB multimedia hard disk enclosure, they're the kind that look more or less like any enclosure, but have a small embedded computer inside allowing them to act as a standalone player. The enclosure's media firmware therefore supports reading off the hard drive's filesystem directly, and can read NTFS. When plugged into a PC it shows up like any other generic external disk. Anyways, getting to the point. At first I tried writing to it with NTFS-3G, and it seemed to work for awhile, then suddenly after copying a massive amount of data (over 200G), some files started to appear 'invisible' to the enclosure's firmware, however, when you plugged it into a PC (windows or linux with ntfs-3g), all the files were present. After much troubleshooting and reading, I read about how NTFS was designed with three namespaces, and that NTFS-3G supports all three, but writes files in POSIX by default, I figured this was a likely cause because it's conceivable that a product like this might not conform 100% to the official NTFS specifications. I decided to test this by doing several experiments, I wrote data from windows to the enclosure, and all of it was readable, then I tried to write a lot of data from linux (ntfs-3g) and again this specific data showed up as invisible, in some cases the top level folder was visible, but anything inside was invisible. Again, on a PC everything is visible. Then I deleted that same data and rewrote it from windows, and it shows up. I did this several times, and also used ntfsinfo from ntfsprogs to check what the namespaces were on certain files. There's more information I might be able to provide on the testing methodology I used, but for now, as a first post, I just want to get the basics on the table. Now, I know this is not an NTFS-3G bug, however, we all know what hardware vendors are like. The fact is that NTFS-3G's behavior in regards to it's default namespace is different than Windows, and this means some devices out there could be incompatible, not just mine. However, before I get flamed, let me say this, I do agree that POSIX should be the default namespace, since it makes sense for UNIX/LINUX users. But what I think is that there should be a mount option to override this default behavior, to make NTFS-3G behave like Windows XP's driver, assigning both Win32 and DOS entries to each file created. There could be mount options to specify them separately, such as: -o ntspace=win32,dos -o ntspace=win32 I've looked in the manpage and something like that doesn't seem to be present. This would potentially increase compatibility with all devices that test only against Windows and nothing else. It is unlikely that any hardware vendors actually take the POSIX namespace (or even the DOS one for that matter) into account when designing their products, so I would not be surprised if there were other hardware out there that has this problem. Oh, and by the way, I did contact the vendor earlier this week and told them there is a problem with their NTFS implementation, however I did not have as much information about the specifics then as I do now. I also have suspicions that they likely licensed their implementation from some other vendor, meaning they probably can't do anything and would have to pass on my problem to their OEM for their firmware, and so on. Anyways, that is my situation. All suggestions and discussion is welcome. Thank you in advance for taking the time to read this [quite lenghty] post.
Sun Oct 05, 2008 04:15
Joined: Tue Nov 21, 2006 23:15 Posts: 1648	Thank you for the interesting description. The vendor should fix their firmware. Windows SFU also creates files in the POSIX namespace, so they have the same problem with Windows too in that case. All namespaces are STANDARD, one can't support only one, or two. NTFS-3G supports all but writes only in the POSIX namespace to maximize interoperability. This 100% conforms to the NTFS specification what the flawless Window interoperability also proves. The POSIX namespace was not only designed and used for UNIX/Linux by Microsoft, but for all operating systems, including Windows and the one your embedded hardware uses. This is a government regulation Microsoft had to comply to be able to run for $$$$$ governmental and other businesses. May I ask what are these 'some embedded hw'? We would like to document and warn people they have a non-conformant NTFS driver. Thank you. Regards, Szaka
Sun Oct 05, 2008 12:01
Hello, thank you for your response. I appreciate it. The particular embedded hardware I am referring to in this case is my MediaSonic Media Player HM2-SU2TV. I understand that the proper fix would be for the vendor to change their firmware, but it is quite unlikely that they will. I also know that even Windows sometimes creates files in the POSIX namespace, I recall seeing some files that're longer than the Win32 character limit. However, even Windows itself has problems and incompatibilities with these files, I have noticed that sometimes if you try to delete such a file it will say things like 'file doesn't exist' or something: http://www.google.com/search?q=filename+too-long In other words, just because the namespace is 100% valid, that doesn't mean that they treat it equally. And most if not all files that the user would be copying to this media enclosure (mostly your movies, music and images) are going to be created using the Win32 & DOS namespaces. They have no reason to comply with my request to fix their firmware. The bottom line here, is that I have hardware that works in both Windows and Linux, but ONLY when I write data from Windows, can the media enclosure's firmware READ the data. Regardless of who's 'fault' it is, or who is to blame, the fact is that the driver on Linux behaves differently than the Windows NTFS driver, and therefore the results with some implementations out there will be different. Like I said, the default can remain POSIX, but why would it be such a bad thing to have a mount option to change it? Free Software and Open Source are about choice, and taking control of your computer, I should be able to tell the driver to write in whatever namespace I chose. Right now I am in a position of being forced to use Windows because I cannot tell the Linux driver to write files in the namespace that I want it to. I want to make it clear, this is not a bug report, it is more of a feature request, I'm not accusing NTFS-3G of having the problem, I already noted that the problem is with the firmware. But adding this simple feature to the driver could easily solve the issue. I'm sorry for the post being long again, but I like to be thorough and I got the feeling that I did not explain myself very well the first time.