exfat pathname mystery

[trantran]

I am thinking of writing a path_name_class that would be easily adaptable to any file system, but I have run in this difficulty: it appears that some file systems allow ALL unicode except null characters in their directory entry (this is the case for example for exfat and many others (as reported by the wikipedia entry "comparison of file systems")).
So here is a mystery I have not been able to solve even after googling a lot: how can you possibly represent a path in those circumstances as a wchar array ?
Is NULL used as a the component separator for those file systems with a path length becoming necessary so that you could for example specify it this way easily this way in a wstring? Or is the path ending specified with double NULL?

[Ancient Dragon]

have you looked at boost file system fuctions? Boost may have already solved your problem for you.

Microsoft has not released the official exFAT file system specification, and a restrictive license from Microsoft is required in order to make and distribute exFAT implementations. Microsoft also asserts patents on exFAT which make it impossible to re-implement its functionality in a compatible way without violating a large percentage of them.

Quoted from here

[trantran]

1) Boost file system allow a constructor with a basic_string with no answer to my question: the examples in the documentation only refer to posix windows
2) The fact that exfat is proprietary is irrelevant. Indeed the "all unicode except NULL" for file name is common to myriad of file systems including proprably open sources one (such as UFS1 for example).
I probably badly frame the problem: the question should be:
How can someone possibly refer to a path in a text file (string) when a file system (whatever it may be) permits "all unicode characters except Null" for filenames?

[Ancient Dragon]

So what's the problem with that? NULL is just a string terminating character, not part of a file name in any file system that I know of. If you have a file that contains a filename that is terminated with a NULL byte then all your program has to do is stop reading the filename when the NULL byte is encountered, the very same way it would if it were terminated with normal line terminating sequence of characters. The NULL byte is not part of the filename, only a terminating byte.

[trantran]

The problem is this:
How do you represent this linux path: "/home/etc/whatever"
in the other filesystem?

And before you try: don't forget you CAN'T use the "/" or ANY other charactacter as a path separator because it could be actually part of the files name so that in the other filesystem: "/home/etc/whatever" could actually a filename and not a path!

[Ancient Dragon]

You would have to know what characer is used instead of '/'. When UNICODE is used the byte sequence of a single character could contain '\0', or NULL, especially of the language is Chinese where characters are represented by graphics and occupy two or more bytes per character.

[trantran]

"You would have to know what characer is used instead of '/'"
You are starting to understand the problem: there is NO character available (except NULL)!

[Ancient Dragon]

so the path might look like this: "'\0'home'\0'etc'\0'whatever'\0''\0'" That is not a text string and won't work with std::fstream, or FILE*. Whoever wrote the file system probably also has a compiler with stream functions/classes that work with it. If not, I don't know how anyone could write a program to run on it.

[trantran]

So we've done full circle and back to my first post, but now you understand the problem.
It would be interesting to see if others have other solution. In particular since many of these file systems are quite old (CBM for example) perhaps some reader have actually used them and could shed a light on how path were specified back then.