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

51–60 of 60 posts

Re: Naming things (2015) [pdf]

#51

Post by heinrichhartman »

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?

yeah. I just can't stand all those dashes ;)

Just make sure to quote your variables in bash.

Re: Naming things (2015) [pdf]

#52

Post by subwayclub »

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…

Have you considered writing an automatic file syntax check/rename? Reading the thread made the idea pop into my head that it could be a useful tool, especially in fast moving or group environments.

I prefer organizing by year and by category(business, code, etc) instead of by client but overall I'm mostly happy to have any organization of my files at all.

Re: Naming things (2015) [pdf]

#53

Post by zokier »

mcphage wrote: post #50
zokier wrote: post #45

Earlier quoted context omitted.

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.

> and then you'd have all these directories sitting around—some of which are useful, and some of which aren't.

Directories do not really cost anything, so carrying them around doesn't really matter that much. You can think them just as simple (hierarchical) tags. If you really cared, doing a (scheduled) GC pass to prune empty branches shouldn't be too difficult to do.

Of course the question if tags are actually good way of organizing things is still open, but that is distinctly different problem than "baking in a single specific organization"; I would even venture to say that it is almost opposite problem, simple tags generally being too freeform and unstructured.

Re: Naming things (2015) [pdf]

#54

Post by stevewillows »

dghf wrote: post #24
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…

> 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. Out of curiosity, why do you have the year/month in the names of both the project folder and the collateral file? And why do you start the names of your final/process/elements folders with undersco…

I keep the dates on both for when I'm searching. For instance, if I'm searching for shirts, I'll see 0701-monkey-shirt.ai, but I draw a lot of these.

Re: Naming things (2015) [pdf]

#55

Post by stevewillows »

subwayclub wrote: post #52
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…

Have you considered writing an automatic file syntax check/rename? Reading the thread made the idea pop into my head that it could be a useful tool, especially in fast moving or group environments. I prefer organizing by year and by category(business, code, etc) instead of by client but overall I'm mostly happy to have any organization of my files at all.

oh man, that would be great. There's probably a way, but I wish all files had something similar to ID3 tags with renaming applications.

Re: Naming things (2015) [pdf]

#56

Post by Someone »

jasode wrote: post #36
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…

>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…

"File managers like MacOS Finder and MS Windows Explorer don't know when 2 files are supposed to be "treated as one unit" vs separately"

They sort-of do, each in their own way. Mac OS has packages: directories with files that the Finder treats as a single item. I think this is mostly implemented outside of the file system; if you give a directory a file name with an extension that some application claims to be an extension for a package, the Finder treats it as a package.

On Windows, when you export a web page from Internet Explorer as "web page, complete", you get a file and an associated folder containing the images of the file. MS Explorer shows them as separate icons, but knows that the two form a unit; when you delete one, it informs you about the existence of the other. I don't know how this is implemented, but suspect it is 100% outside of the file system, too.

Also, classic Mac OS had resource forks: a single alternate stream for every file. Text editors used it, for example, to store the cursor position, line wrap settings, etc. across saves.

Re: Naming things (2015) [pdf]

#57

Post by Someone »

kutkloon7 wrote: post #12

Those filenames look terrible to me. BRAFWTNEGASSAY doesnt make any sense. To distinguish between the filenames you actually have to read the full filename, and with such long filenames chances are they won't fully be displayed, so that you have 2013-06-26_BRAFWTNEGASSAY_Plasmid-Cellline-100-1MutantFrac... For the first four files. Keeping cruft out of your filenames seems like a much, much better way to name files.…

"most systems keep track of the creation data"

You only need one tool that doesn't quite do things right to lose that:

- file copy programs need to explicitly set the creation date back to that of the original file.

- when you do save a file in an editor, it typically writes a complete new file (ideally through a write temp file/delete/rename dance). Again, the program may forget to reset the creation date of the new file to that of the original.

- I don't think got even _stores_ creation time stamps in repositories.

I've seen too many files with obviously bogus creation time stamps to put much trust in the creation dates of files.

Re: Naming things (2015) [pdf]

#58

Post by [deleted] »

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…

[deleted]

Re: Naming things (2015) [pdf]

#59

Post by mcphage »

zokier wrote: post #53
mcphage wrote: post #50

Earlier quoted context omitted.

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.

> and then you'd have all these directories sitting around—some of which are useful, and some of which aren't. Directories do not really cost anything, so carrying them around doesn't really matter that much. You can think them just as simple (hierarchical) tags. If you really cared, doing a (scheduled) GC pass to prune empty branches shouldn't be too difficult to do. Of course the question if tags are actually good…

That seems like a lot of trouble to accomplish something not quite as good as what she's already accomplished, without any of the work.

Re: Naming things (2015) [pdf]

#60

Post by hobarrera »

marcosdumay wrote: post #42
l0b0 wrote: post #35

Earlier quoted context omitted.

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.

Licensing is a problem for SOME formats.

ZFS, ext4, and plenty of others used by BSDs and Linux distros have no licensing issues.

Also, if any player cared to win the filesystem war, they'd open up their spec royalty-free.

Post reply on HN