• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Not so long filenames
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Not so long filenames


  • Subject: Re: Not so long filenames
  • From: "Gerriet M. Denkmann" <email@hidden>
  • Date: Tue, 28 Oct 2008 12:50:26 +0100


On 28 Oct 2008, at 01:39, Jeremy Pereira wrote:


On 26 Oct 2008, at 09:55, Gerriet M. Denkmann wrote:


On 26 Oct 2008, at 00:30, Postmaster wrote:


On 14 Oct 2008, at 21:00, Gerriet M. Denkmann wrote:


On 14 Oct 2008, at 18:07, Jason Coco wrote:


On Oct 14, 2008, at 11:28 , Gerriet M. Denkmann wrote:


HFS+ stores files in decomposed UTF-8. Checking the system headers,
"system headers" is kind of vague: which file exactly do you have in mind?

it can store files with a maximum file name length of 255 bytes. How do you get 256 bytes of UTF-8 into 255 bytes?

Checking the system header hfs_format.h for HFSUniStr255 one sees that it can store file names with a maximum length of 255 u_int16_t.
And there is no real problem of putting the 128 shorts of Utf-16 into 255 u_int16_t.

It's actually the VFS layer I was thinking of. The OS X VFS uses UTF-8 (otherwise there would be no backward compatibility for calls like open(2) etc). I got the 255 byte limit by looking at struct dirent defined in /usr/include/sys/dirent.h which is the structure used in the readdir syscall.


I have just tried getdirentries() which uses the dirent structure described in /usr/include/sys/dirent.h .

The result was (for me) quite a surprise.
What I did:
1. created a file in Desktop
2. renamed it in Finder to: "𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀 𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀 𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀 𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀".
(128 Utf-16 shorts, but 256 Utf-8 bytes).
3. ran getdirentries() and got:
file (255)"𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀 𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀 𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀 𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀𐐀#185D41"
4. used open() and read() with this (seemingly garbled) filename - and it just works!


But open() and  fopen() also work with the real filename.

And: renaming a file in Finder with this (garbled) name does not work: Finder claims that this name is already in use. Which is not true: HFS+ has only the real filename stored.

No idea who does the translation between real filename and garbled version.

Very strange indeed.


Kind regards,

Gerriet.

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Not so long filenames
      • From: Jean-Daniel Dupas <email@hidden>
References: 
 >Not so long filenames (From: "Gerriet M. Denkmann" <email@hidden>)
 >Re: Not so long filenames (From: Jason Coco <email@hidden>)
 >Re: Not so long filenames (From: "Gerriet M. Denkmann" <email@hidden>)
 >Re: Not so long filenames (From: "Gerriet M. Denkmann" <email@hidden>)
 >Re: Not so long filenames (From: Jeremy Pereira <email@hidden>)

  • Prev by Date: RE: Can we ask iPhone questions yet?
  • Next by Date: Turning off Auto Complete feature for NSTextField
  • Previous by thread: Re: Not so long filenames
  • Next by thread: Re: Not so long filenames
  • Index(es):
    • Date
    • Thread