Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Naming things (2015) [pdf]

www2.stat.duke.edu

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Naming things (2015) [pdf]

#41

Post by efitz »

The author forgot to write down the most important reason for the whole exercise: file transfer.

Modern operating systems index the contents of your files, so finding all your files on project "foo" is only a search away. If you are a GUI user, then file naming isn't really that important for locating data on your machine.

Where file names matter is because there is 40 years of cruft out there which absolutely refuses to move metadata along with files. So you can touch your files to set dates, organize them in directories or tag them to your heart's content in Mac OS or Windows, but you will lose all that information when you attach the file to an email or put it in DropBox.

So you only have a choice of two places to put metadata in such a way that the metadata will be carried along with the file- the file name or the file contents.

Putting the data in the file contents lacks discoverability and in many cases the applications you use to manipulate the files don't allow for additional metadata anyway. Also, some file types (Word .docx files, jpegs, MP3s) get their metadata updated and/or scrambled when you open them with specific applications. So really your only valid choice is to put it in the file name.

The author's specific recommendations (use underscores and hyphens for delimiting) assume that you really want to access the files with the command line and use globbing. Other than that implication, the recommendations are sound.

Re: Naming things (2015) [pdf]

#42

Post by marcosdumay »

l0b0 wrote: post #35
pjc50 wrote: post #32

The real lesson of this discussion seems to be: metadata has failed our expectations. All this ancillary stuff that we'd like attached to files, like dates, client names and projects, versions and so on, are metadata. Some systems keep metadata in files: EXIF, Word, PDF. Some systems have conventions for this instead: header blocks in source code. But if neither of those applies? Only place you can put it reliably is…

If OS vendors could get over their "not invented here" syndrome with respect to default file systems we might see something a little bit more sane than FAT as the one interchangeable format. This is necessary but not sufficient to make decent file systems widely available. Then we can start hoping for such trivial features to become available.

Everybody shops for the best filesystem around that they can use. The problem is, licensing is a problem.

In other times, the industry would solve this by creating a standard for metadata interchange, but one of the biggest players gets a too big to ignore amount of revenue from FAT, and is able to block any attempt at standardizing.

Re: Naming things (2015) [pdf]

#44

Post by dsp1234 »

demonshalo wrote: post #40
jasode wrote: post #36

Earlier quoted context omitted.

>lesson of this discussion seems to be: metadata has failed our expectations. I've written several "disk and file catalog" utilities over the years so I inevitably spent a lot of time thinking about the "metadata" problem. I think the issue is that it's impossible to solve metadata in a universal way that satisfies all scenarios. This is why metadata often ends up being inscribed into the filename. It's the "least wo…

Couldn't we just come up with some convention for "expanded filenames" where the meta-data is included in the file name itself? In the UI portion, you see what you see now, no difference, but say anything after the // delimiter in the file name is considered meta data and not shown in the windows/terminal UI. Not sure if it's a good solution but if I were to put the meta data somewhere I would somehow try to put it i…

This is partially what filesystem forks/streams were supposed to be for. The big problem, as mentioned, is that this works for the OS, but isn't somehow transferred to third parties.

https://blogs.technet.microsoft.com/askcore/2013/03/24/alter...

https://en.wikipedia.org/wiki/Fork_(file_system)

Re: Naming things (2015) [pdf]

#45

Post by zokier »

mcphage wrote: post #39
k_sze wrote: post #25

If you look at the filename examples, there seems to be an implicit suggestion of naming a group of related files using a common prefix. If one needs to distinguish groups of files, why not just put them in directories ? That's the reason directories exist, no? I can somewhat understand if some (bad) software is written to look for files only in a single directory and you have to put everything there. But otherwise,…

Because you might want to group files in an order other than first element to last element. Putting them in directories bakes in a single specific organization, rather than letting them be organized as desired on the fly.

Isn't that simply solved by (hard)linking the files in whatever directory structures needed? There is nothing really in directories that bakes in a single specific organization.

Re: Naming things (2015) [pdf]

#47

Post by zokier »

grif-fin wrote: post #38
heinrichhartman wrote: post #37

I name my files like this: 2017-04-04 #S4907 #Choir List of names.pdf 2017-04-05 #EXCITE #S=5005 Notes on Data Repositories.pdf 2017-04-06 #ARAG #S=5031 #Amount=14.2 #CUR=EUR Invoice.pdf with the following semantic: * date. Every file name is prefixed with the ISO date to facilitate sorting * tags. The syntax # to categorize documents with tags. * key-value pairs. The syntax $ =value let's us attach structured inform…

You are suggesting a file name format with spaces in it?

Whats wrong with spaces?

Re: Naming things (2015) [pdf]

#48

Post by demonshalo »

dsp1234 wrote: post #44
demonshalo wrote: post #40

Earlier quoted context omitted.

Couldn't we just come up with some convention for "expanded filenames" where the meta-data is included in the file name itself? In the UI portion, you see what you see now, no difference, but say anything after the // delimiter in the file name is considered meta data and not shown in the windows/terminal UI. Not sure if it's a good solution but if I were to put the meta data somewhere I would somehow try to put it i…

This is partially what filesystem forks/streams were supposed to be for. The big problem, as mentioned, is that this works for the OS, but isn't somehow transferred to third parties. https://blogs.technet.microsoft.com/askcore/2013/03/24/alter... https://en.wikipedia.org/wiki/Fork_(file_system)

thanks for the links!

Re: Naming things (2015) [pdf]

#49

Post by bigmanwalter »

stevewillows wrote: post #23

I'm constantly harping on everybody to pay attention to their file naming. I'm a graphic designer, so for me everything is Client/YYMM-Project/_FINAL/YYMM-COLLATERAL-NAME Within each project there is a _PROCESS folder with a _ELEMENTS subfolder for pieces the client has given me to work with. For invoices I do YYMMDD-ClientName-Project-Sum.pdf. When the invoice is paid, I rename the file to add -PAID- before the clie…

That's an awesome scheme. I'm going to try incorporating it into mine!

Re: Naming things (2015) [pdf]

#50

Post by mcphage »

zokier wrote: post #45
mcphage wrote: post #39

Earlier quoted context omitted.

Because you might want to group files in an order other than first element to last element. Putting them in directories bakes in a single specific organization, rather than letting them be organized as desired on the fly.

Isn't that simply solved by (hard)linking the files in whatever directory structures needed? There is nothing really in directories that bakes in a single specific organization.

You could, and then every time you wanted to organize things differently you'd hardlink a new set of directories, and then you'd have all these directories sitting around—some of which are useful, and some of which aren't.

Which is to say: yes, you could, but it seems like a worse idea than just not putting them in directories at all, and relying on the OS's (strong) search features to get you want you want.

Post reply on HN