7 ms·

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

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

bsaul 7y ago
That's probably a clue something needs to be done at the OS level regarding FS integration with cloud syncing systems and permissions.
- monsieurbanana 7y ago
  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.
  - bsaul 7y ago
    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.
    - monsieurbanana 7y ago
      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.
      - bsaul 7y ago
        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.
  - michaelmior 7y ago
    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.
- nolok 7y ago
  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.
- Symbiote 7y ago
  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://en.wikipedia.org/wiki/Archive_bit ² https://www.samba.org/samba/docs/using_samba/figs/sam2_0801.gif https://www.samba.org/samba/docs/using_samba/figs/sam2_0801....
  - michaelmior 7y ago
    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.
tonyedgecombe 7y ago
We clearly need a common standard for this: https://xkcd.com/927/ https://xkcd.com/927/
jrockway 7y ago
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.
- michaelmior 7y ago
  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.
  - 7777fps 7y ago
    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.
    - tmpz22 7y ago
      Don't forget the git rm -r --cached ./node_modules!
    - michaelmior 7y ago
      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.
deleted 7y ago
[deleted]
lonelappde 7y ago
What missing is .folderinfo/ to hold those things, akin to HFS resource fork or file attributes

bsaul 7y ago

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

monsieurbanana 7y ago
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.
- bsaul 7y ago
  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.
  - monsieurbanana 7y ago
    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.
    - bsaul 7y ago
      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.
- michaelmior 7y ago
  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.
nolok 7y ago
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.
Symbiote 7y ago
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://en.wikipedia.org/wiki/Archive_bit ² https://www.samba.org/samba/docs/using_samba/figs/sam2_0801.gif https://www.samba.org/samba/docs/using_samba/figs/sam2_0801....
- michaelmior 7y ago
  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.

tonyedgecombe 7y ago

We clearly need a common standard for this: https://xkcd.com/927/ https://xkcd.com/927/

jrockway 7y ago

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.

michaelmior 7y ago
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.
- 7777fps 7y ago
  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.
  - tmpz22 7y ago
    Don't forget the git rm -r --cached ./node_modules!
  - michaelmior 7y ago
    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.

deleted 7y ago

[deleted]

lonelappde 7y ago

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