File naming schemes and quirks

[jimthing]

@macguyver

Just out of curiosity, do you have a pro/con rationale for using dots vs hyphens as separators?

Yes, personally I do. But I do understand many like to stick to the more simple ISO system of yyyy-mm-dd for everything, as you mentioned. And others may prefer underscores between sections (2022-2024_Big_Bank_ ac_1234) to avoid line breaking in some uses including URLs etc.

I use hyphens (aka dashes) to mean ‘between’ dates for files and folders. Some examples:

2022-2024 - Big Bank - ac 1234
Something which ran over those three years, like say a folder name for a bank account (using last 4-digits of ac#).

2024.05.24.Fri - Big Bank - ac 1234 - ac closed confirmation.pdf
Something which is dated on that date, like say a bank letter. I include the day for many things to aid tracking comms, for example to help understand why something didn’t come the next day because it was a weekend.

2024.05-11 - something project
Something which is dated between May and November of that year, like say a small project.

2024.05-2025.02 - another project
Something which is dated between May 2024 and February 2025, like another small project.

You get the kind of idea. My file names can be quite long, but simply moving the file to folder location then copy-paste-editing of a previous file name in the location folder, gets things named quickly. ;-)

EDIT: I wonder if Windows 11 still has that total file path length restriction of 256 260 chars or whatever it was?
(I’m basically an Apple-only user, but sometimes simplify names for a simple share to someone in Win-land, as needed).

[macanix]

Just a note about using periods, if you ever move to an SMB or NAS that is shared with Windows, you want to avoid using periods and long filenames, along with various symbols. A site I was recommended to has good tips on this and more!

[josehill]

@jimthing

I wonder if Windows 11 still has that total file path length restriction of 256 chars or whatever it was?

The default path length on Windows 10/11 is 260 characters, but it can be increased to approximately 32k characters by editing the Registry or by running various utilities and configuration tools to enable “Win32 long paths”.

[jimthing]

@macanix

Just a note about using periods, if you ever move to an SMB or NAS that is shared with Windows, you want to avoid using periods and long filenames, along with various symbols. A site I was recommended to has good tips on this and more!

Why periods? (That linked to piece didn’t explain specifically.)
AFAIUI, only ending with a period is an issue (or start, as they’re hidden files on many OS’s), not in the middle?

@josehill

The default path length on Windows 10/11 is 260 characters, but it can be increased to approximately 32k characters by editing the Registry or by running various utilities and configuration tools to enable “Win32 long paths”.

So presumably that means the ‘average’ user (home users, I guess) is stuck on 260 chars then?
What happens if one shares a file that that creates a >260 path length to such users?

[josehill]

@jimthing

So presumably that means the ‘average’ user (home users, I guess) is stuck on 260 chars then?
What happens if one shares a file that that creates a >260 path length to such users?

IIRC, it will not be accessible via the Windows interface/API, and Windows will report a path length error, but it will remain on the filesystem without any issues. I don’t recall what happens if you attempt to delete parent directories containing files/folders with long paths if the system is not configured to work with them. I suspect it will just yield an error, but I might be wrong.

Note that the Win32 path length setting is a Windows setting, not a filesystem setting.

[Shamino (David C.)]

@josehill

The default path length on Windows 10/11 is 260 characters, but it can be increased to approximately 32k characters by editing the Registry or by running various utilities and configuration tools to enable “Win32 long paths”.

It’s weirder than that. This path length limit only applies to the older file-system APIs, that uses 8-bit characters. The “modern” APIs that accept Unicode characters have always had a 32K limit (effectively unlimited).

So a Windows app that uses the Unicode-based APIs (as all non-ancient Windows apps should be doing) has no such limit.

The 8-bit file system APIs have this limit, going back to the days of MS-DOS when there was a 256 byte buffer for each disk volume. The 260 character limit was the drive prefix (C:\ - 3 characters) plus the 256 byte buffer plus a terminating NUL character (3 + 256 + 1 = 260). Microsoft kept this legacy of MS-DOS in Windows NT for backward compatibility - they apparently believed that apps would have lots of hard-coded 260 byte buffers for path names without any code to prevent buffer overruns. I have no idea how common this practice was, since it was always bad software design.

Microsoft removed this limit from the 8-bit file API in Windows 10, bumping it up to the same 32K character limit that the Unicode-based file API has always had. But they made it opt-in - you need to explicitly enable the feature via a registry key. Presumably because they’re still worried about poorly-written apps with hard-coded 260 byte buffers.

The frustrating thing is that some core parts of Windows (including the desktop’s Explorer, I believe) are still running some old code that uses these 8-bit APIs, making them subject to the path limit.

I always turn on this registry option and it’s never caused me any problems with any app I own.

@macanix

you want to avoid using periods and long filenames, along with various symbols

I also don’t know why multiple periods should be a problem. I do this all the time on my Windows systems without a problem.

Trailing spaces and periods are supported by the file system APIs, but not by Microsoft’s shells (graphical and CLI), which could make these files hard to access.

As for using symbols, Microsoft has always reserved some characters. They are well documented and are: <>:"/\|?*. Windows also reserves specific names for devices (e.g. COM# for a serial port or LPT# for a printer). Everything else is OK, as far as Windows is concerned, but I would recommend avoiding most symbols if possible, because Unix shells use quite a lot of them for various things and not all shell scripts will quote filenames properly, leading to incorrect behavior of those scripts.

@jimthing

What happens if one shares a file that that creates a >260 path length to such users?

Windows users may or may not be able to open the file, depending on the version of Windows, the app being used to launch/open the file and system configuration.

See also:

• Maximum Path Length Limitation - Win32 apps | Microsoft Learn
• Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn

[macanix]

Sorry- I should have stated I think the point about periods is not to start a filename with one, as well as not using characters like / \ ? $ # … but that is just what I was told from years of working with Windows server admins, and such.
I mean, today’s modern interface/GUI probably doesn’t care, and if most just use MacOS, I don’t think its an issue. But I have had some utility/file software throw an issue with filenames. Sorry, I have no example.

I just deal with some users on our NAS that either name files with - inbetween naming or use periods. I guess its not as bad as it used to be?

[Simon]

You don’t want periods at the start of a file name on a Mac. In good UNIX manner, that hides the file. Finder will tell you that such file names “are reserved for the system”. Not joking.

[macguyver]

I see your logic, Jim. The hyphen is better suited to indicate a range, or connection between two values (ie. dates).

I sometimes use a compact form such as “2024jun30”, or “30jun2024”. This method works well for avoiding non-alpha/num characters or conflating the date with the other filename info, while using less character spaces overall. Unfortunately, it makes searching and sorting problematic.

I use periods in the middle of filenames somewhat regularly, but if doing serious work or sending anything electronically, I will adjust the name to make it more system and cross-platform friendly.

I have frequently used hyphens or underscores (and occasionally a leading space… gasp!) as the first character to bump the item up to the top of a Finder directory list.

Hmm… perhaps we have gone off topic a smidge?

[Shamino (David C.)]

@macanix

I think the point about periods is not to start a filename with one, as well as not using characters like / \ ? $ #

As was already mentioned, Unix-like systems (including macOS 10.0 and later) treat a leading period as a hint that the app should hide the file. It is still valid and accessible, and the underlying APIs don’t care, but most software will make a point of hiding these files unless explicitly told to present them.

As for the various symbols, the Windows ones I mentioned are actually not allowed by the Windows APIs. I don’t specifically remember what Windows will do if it encounters these in a filename on a storage device. If it’s local storage (e.g. a floppy disk or flash drive), the file might be inaccessible. If it’s on network storage, I think the network file system drives will map the problem characters into something else.

@macanix

I guess its not as bad as it used to be?

it’s definitely better than in the past, where systems would just refuse to access network files with names that don’t match the local OS’s restrictions. But it’s still a good idea to be careful with things like that because:

• There may be users with old operating systems that will still choke on these filenames
• Some apps may be making unwarranted assumptions, like assuming that every file on a volume is compatible with the local OS, or using old 8-bit APIs instead of modern Unicode ones.
• When characters are mapped for compatibility, users won’t see exactly what you created, which may be confusing.

But if it’s just your personal NAS and you own all of the computers, then it really doesn’t matter that much. The issues really only show up in an environment where there are many users running different systems, like a corporate or university network.

[jimthing]

[topic split from main subject now]

@macguyver

I sometimes use a compact form such as “2024jun30”, or “30jun2024”. This method works well for avoiding non-alpha/num characters or conflating the date with the other filename info, while using less character spaces overall. Unfortunately, it makes searching and sorting problematic.

The problem is SORTING order with those examples: when using ‘jun’ ‘jul’ the jul’s numbers will sort above jun’s, and “30jun2024” type of word order won’t sort properly either, for example.

Hence numbers being somewhat preferable (and using a splitter to make reading easier: 2024.01.04 or 2024-01-04 vs just 20240104).

@macguyver

I have frequently used hyphens or underscores (and occasionally a leading space… gasp!) as the first character to bump the item up to the top of a Finder directory list.

Yes, that sounds like me too. Sometimes I do this when I’m sorting a load of files in one directory to get them together at the top (then select all of those and make a folder, then mass rename to remove leading space/dash/underscore), then repeat as needed. As a guess, I suspect that’s an old trick for many users, old and new, lol! ;-)

[Will_M]

@macguyver

I sometimes use a compact form such as “2024jun30”, or “30jun2024”. This method works well for avoiding non-alpha/num characters or conflating the date with the other filename info, while using less character spaces overall. Unfortunately, it makes searching and sorting problematic.

If I wanted to use alpha characters and I was concerned about sorting, I would use a naming convention like 202406jun30. The month information is redundant, but it does allow an alphabetic month and it will sort well. There is a two character increase in the length (three if 2024-06jun30 is preferred), but I would consider that a small price to pay for proper sorting. (I don’t feel a need to include letters in the date nor a spacer between the year, month, and date. To keep the date string from being purely numeric and because I sometimes want to know what the day of the week was, I use a format like 240630u. It cannot be interpreted as a number and it reminds me that Jun 30 fell on a Sunday.)

[jimthing]

@Will_M

I use a format like 240630u. It cannot be interpreted as a number and it reminds me that Jun 30 fell on a Sunday.)

Tue or Sun - the second letter of both is a ‘u’?

[mpainesyd (Michael Paine)]

From my Windows days (more than 2 decades ago) I generally use an underscore for spaces in a filename and dashes for linked words:
Home_Accounts_2024-2023.xlsx

BTW - when I first created webpages in the 1990s filenames were limited to 8 characters as were DOS apps. I tend to still use short filenames out of habit.

[james.cutler (James R Cutler)]

Continuing with sortable time and date in file names compatible with unix, linux, macOS, Windows, and most programming languages:
ISO Standard 8601 is your friend.
yyyy-mm-ddThh:mm:ss.sss is the full spec format, but the following short forms ARE both allowed by the standard and are more useful in filenames:
yyyy-mm-ddThhmmss or yyyymmddThhmmss
Omit the time where not needed.
Side note: spaces in filenames may be replaced with underscore (_) to be easier to parse in zsh, bash, and the like, removing the requirement for quoting.

[Simon]

I want as few characters as possible, good sortability, and compatibility with other OSes and various file transfer mechanisms. So typically something like 20240630-1731-Description_Yada_v2.txt

[Will_M]

@jimthing

Tue or Sun - the second letter of both is a ‘u’?

Sunday, of course. Why? Because that’s my convention.

This is in the weeds. Normal people should skip the rest of this post.

When I went to undergraduate college, the school denoted the class days using the letters MTWRF. I stuck with that scheme until I became associated with a school that used MTWHF, and that’s what I use now. For Saturday and Sunday, I use the second letter of the day.

If I wanted complete consistency (first letter of the day unless there is a conflict, then second letter), I might use LAEJVSD. Complete consistency is not that important to me.

[jimthing]

I understand. I suppose one could do Mo/Tu/We/Th/Fr/Sa/Su – if one wanted to ‘splash out’ on an extra letter, but not use three, lol!

Amusing how everyone has their own naming schemes, depending on personal preference, uses needed, OS’s used, or whatever.

Interestingly, Apple offer date order with periods (2024.08.19) as an option in Settings now, under General > Language & Region > Date Format.

screenshot (UK):

@Will_M

If I wanted complete consistency (first letter of the day unless there is a conflict, then second letter), I might use LAEJVSD. Complete consistency is not that important to me.

Lundi
mArdi
mErcredi
Jeudi
Vendredi
Samedi
Dimanche

…lol!

[colleenthompson]

Dates: after many years I’ve settled on YYMMDD, as in 240703, at the front of file names. This has the advantage of sorting chronologically when alphabetized. As for readability, once you get used to it it’s perfectly readable. A four-digit year and/or hyphens or other separators means more typing, plus I found hyphen & underscore to be difficult when touch typing. I avoid using periods because of a few occasions when the operating system became confused about the filename extension.

[nello]

@colleenthompson

A four-digit year and/or hyphens or other separators means more typing, plus I found hyphen & underscore to be difficult when touch typing.

I automated the creation of a text string for the current date in the format YYYY-MM-DD using a PopClip Extension Snippet. This Snippet will also transform existing dates into other formats.

Date converter snippet