Hacker News Reader

Comment by NikolaeVarius | Hacker News Reader

I can imagine a world where a arbitrary directory is filled with gitignore, dropboxignore, googledriveignore, backblazeignore, s3ignore, rsynciginore, dotignore, ipfsignore . . .

Goddamn, stop the world I want to get off

View on HN

I think the problem here is poor tooling that contaminates your working directory.

If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar). Thus there are no artifacts to gitignore. OCI container builds ("docker images") are done by simply adding artifacts controlled by a build rule into the image (rather than starting a vm/container, copying a working directory into the container, and running random shell commands).

To summarize, I think the problem is that node puts packages in your working directory instead of some other location, causing you to have to ignore them. It is reasonable to check in your dependencies, in which case node's strategy is fine. But you can compare this to something like go, which puts all modules in $GOPATH/pkg/mod and if you want to check in your modules, you run "go mod vendor" and it creates a vendor/ directory in your working directory to check in. All of these ignore files exist to work around other packages; it's not git or docker or dropbox's fault that some tool you use contaminates your working directory. Plenty of designs exist for those types of tools that don't.

Personally I prefer that build artifacts end up somewhere under my current working directory. That means if I want to clear everything out related to a project, it's easy to do so without interfering with anything else.

Yes, as frustrating as it is to need on occassion to rm -rf /node_modules and start again to fix things, at least that's an option.

Don't forget the git rm -r --cached ./node_modules!

Of course it still would be an option if these were stored out of tree, but it means I need to know where that is. I also have the potential to affect other unrelated projects.

I suppose this could be addressed by the tooling, if there was an easy way to get it to echo the target, and it made sure to always keep things separate.

> If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar).

That is a terrible design, as it makes parallel builds error prone.

Bazel is the king of parallel builds though, at work we can spread out 100 actions wide across across a cluster of machines, and the only reason it's that small is we have no real need to go wider...

Output directories are unique by the user and source project workspace directory. Output artifacts don't clobber, even though they are all in ~/.cache.

Other reasons to avoid the home directory:

1. It might be NFS mounted.

2. Space might be an issue and more difficult to plan for if build outputs are going there.

The location is not hard-coded and can be configured with the --output_base flag.

That's probably a clue something needs to be done at the OS level regarding FS integration with cloud syncing systems and permissions.

All major OS already have a permission' system. It's on dropbox & co to honor them.

On linux you can create an user group named "cloud", and allow dropbox to only sync files that belong to that group.

Except dropbox will be totally unaware and try to access it.

What i envisionned was more like a "control center" app of all the outgoing (and incoming) pipes from your FS to syncing systems, with both last syncing time, configuration, etc. A little bit like what's already happening for mail and calendar integration into iOS applications, only for files and on the desktop.

Sorry, I edited my post before reading yours.

Yes, right now Dropbox would probably crash, but that's their problem. I really don't think it's something that should be handled by the OS when they already have a solution for it.

Depending on wether you're a linux, windows or mac user, you'll probably have different expectations on what the OS is suppose to provide by default.

This isn't really a great solution when I have files that are autogenerated. I either have to have the default group be "cloud" and then go back and chgrp these files when they are generated so they don't sync. Or I have to have the default group be something else, and inevitably forget to chgrp for files that I do want backed up.

I really don't think this should be handled at FS level.

robots.txt didn't need to know about who the robot was or what the hosting server was.

Windows (and some other OSs) have/had an "archive bit" ¹. It used to be visible in the file properties, next to the read-only and hidden attributes, and was labelled "Archive" ²

¹ https://en.wikipedia.org/wiki/Archive_bit

² https://www.samba.org/samba/docs/using_samba/figs/sam2_0801....

Some file-system level property could work, but the semantics of the archive bit don't match. For files I want to be ignored, I don't think it makes sense to mark them as backed up, which is what the archive bit was designed for.

What missing is .folderinfo/ to hold those things, akin to HFS resource fork or file attributes

We clearly need a common standard for this:

https://xkcd.com/927/

Reply on news.ycombinator.com