[pdf-devel] Re: Disk filesystem module questions

[jemarch]

   >  * First thing in the function is calling pdf_fsys_get_host_path(),
   > which internally calls pdf_text_get_host(). After that call, we get a
   > host_path and a host_path_size. The problem is that it seems assumed in
   > the source code that the host encoded string is NUL-terminated, as the
   > host_path_size is no longer used. But this may be false. That string
   > is used in GetDiskFreeSpace() or statfs(), and both expect a
   > NUL-terminated string. For GetDiskFreeSpace, the NUL-terminated string
   > should really be a double-NUL terminated string "\0\0", as the expected
   > data is a Unicode string (in UTF-16BE). For statfs I guess it should be
   > UTF-8 encoded string. So, instead of getting the host-encoded
   > representation of the filepath, I think that we should get the
   > UTF-16BE-encoded representation in Windows and the UTF-8 representation
   > in Posix systems. Note that in Windows, you can also use
   > single-NUL-terminated ASCII path in the same function, if the path is
   > only composed of ASCII characters; but to do it correctly we should only
   > use the Unicode representation.
   > 
   Thats probably a good plan. Though I'll have to think about it further. My 
gut
   feeling right now is that its good.

I agree. The UTF-16BE in Windows and UTF-8 in POSIX seems to be a
sensible solution.

   > 
   > * GetVolumePathName (windows). I saw the #if 0 deactivating the usage of
   > GetVolumePathName in the code. Is it only deactivated because it's not
   > available in mingw? The provided approach won't work for UTF-16BE
   > encoded filesystem paths.
   > http://msdn.microsoft.com/en-us/library/aa364996(VS.85).aspx
   > 
   Thats a question for Jose because I'm pretty sure he wrote that
   portion.

/* GetVolumePathName is declared but seems to not be implemented in
   mingw -jemarch */

I didn't found a suitable solution for that, so I went to:

/* So lets do the piggy hack that wont work with relative paths nor
   with multi-byte encodings */

Do you know of any solution? If not, I suppose that the piggy hack
could be adapted to use the pdf_text routines and thus work with other
encodings other than ASCII. It is possible?

   > * GetDiskFreeSpace (windows). From the info in MSDN: "The
   > GetDiskFreeSpace function cannot report volume sizes that are greater
   > than 2 gigabytes". We should use GetDiskFreeSpaceEx, which has a
   > different API.
   > http://msdn.microsoft.com/en-us/library/aa364937(VS.85).aspx
   > 
   Think Jose wrote that, but good catch no less. I hope we aren't reading PDF's
   that big though :-| (haha).

Please use GetDiskFreeSpaceEx if possible. 

   > BTW, the unit tests to test the Disk Filesystem are the generic ones
   > that Hans is doing, right? FS#24?
   > 
   Think so, it interfaces with the "Filesystem" interface, not actually the 
disk
   filesystem implementation which is the default.

Yes. We will use the same unit tests for all the filesystem
implementations.