Re: Rationale for aligning data on even bytes in a Unix shell file?

On 5/7/2025 1:26 PM, BGB wrote:

On 5/7/2025 8:45 AM, Scott Lurndal wrote:

BGB <cr88192@gmail.com> writes:

On 5/6/2025 6:19 PM, Janis Papanagnou wrote:

On 06.05.2025 20:01, BGB wrote:

[...]
>
The partial rationale here being that the directory entries in this case
were fixed size (like FAT, albeit with longer names), and this could
potentially make the difference between using a single directory entry
or needing a more complex LFN style scheme. Though, in this case, the
default name length is 48, and it is rare for a filename to not fit into
48 bytes.

>
You mean rare in your application areas?
>
This appears to me like a very conservative size. While I'd agree
that it's probably a sensible value for own files with explicitly
chosen file names a lot of files that are downloaded regularly do
have longer file names. A quick check of my "Documents" directory
(that contains both, downloaded files and own files) shows a ratio
of 1563:629, i.e. roughly about 30% files of "document" type with
lengths > 48 (there's no files with a file name length > 128).
>
I recall someone here recently spoke about chosen lengths of 255
(or some such)for file names, which seems to be plenty, OTOH.
>

>
>
Running quick/dirty stats of everything on my "K:" drive, roughly 2
million files of various assorted types.
>
Stats (file names less than N bytes):
   16: 66.40%
   24: 87.85%
   32: 95.38%
   48: 99.31%

>
Are you considering the entire path, or just the final component?
>

 Here, only the final:
   "whatever.txt"
 Along with each directory (on lines where the final component is the directory).
 The directory names are not counted for each line though, as this would over-count the directory names. So, effectively, it is only counting the final name component of each line.
 The list of drive contents in this case generated in WSL via the "find" command.
  These component names are what the filesystem actually stores.
  Combined path length can be somewhat longer.
   A traditional limit is 260 chars though.
 There wasn't a well defined path-length limit in my projects, though informally typically somewhere between 256 and 768 bytes.
 It is rare to see a path over 256, but, "if doing it properly" a consistent length limit of, say, 512 or 768 would make sense. Going any bigger is likely needlessly overkill.
 

Full paths will exceed the 48 bytes frequently, this, for example
is 142 bytes.
>
/work/music/Blues/Howlin' Wolf/The Chess Box (1963 - 1973) (disc 3)/20 - The Red Rooster (London Sessions w false start and dialog) (1970).wav

 We don't usually store full paths in a filesystem, as each directory exists as its own entity.
 So, say, if broken down:
  5 chars ("work")
  6 chars ("music")
  6 chars
  13 chars
  37 chars
  75 chars.
 Longest name counted here would be 75.
 

Self correction:
I had used the text editor column here to count characters, which was off by 1.
So:
   6, 5, 5, 12, 36, 74.
Pattern still holds, and all apart from the final name fall within a 48 byte name limit....
In my custom FS, this final name would require 2 consecutive directory entries (or 128 bytes of storage in the directory). This is the most common case (when the 48 byte name fails, and would cover most of the rest of the names, as names exceeding 100 bytes are rare, even with "Whole Sentence As a File Name.txt" style naming conventions...).