Ask HN: How do you manage your filesystem?
3 comments
Projects go in a shallow hierarchy, one folder per project. Most downloaded files go in one place. I just try to name things sensibly so I can find them later by searching. Filesystems used to slow down quite a bit with lots of files, so I moved the downloads into subdirectories by year. Haven't had this trouble in the last few years though so I've skipped it.
The only thing I enforce structure on are my photos, which go in C:\photos\source\yyyy\yyyymmdd\
The camera makes a new folder every time the image number rolls back to 0000, or 1000 photos are taken... those subfolders get moved into the above folder.
I never edit a photo, I always work on a copy. The last time I edited a photo directly, I downsampled the best photo I ever made of a friend by 1/4, and couldn't recover it. It's been decades since that day, and that mistake, and that new rule, and he's since passed. It's a lesson I'll never forget.
---
Programming projects get a folder on C:\, and I copy the .gitignore from y last project to exclude a ton of crud from the repo. Everything gets pushed to github, private or public depending on the nature of the code.
---
Additionally I back up everything to backblaze because it's saved my bacon a few times already.
The camera makes a new folder every time the image number rolls back to 0000, or 1000 photos are taken... those subfolders get moved into the above folder.
I never edit a photo, I always work on a copy. The last time I edited a photo directly, I downsampled the best photo I ever made of a friend by 1/4, and couldn't recover it. It's been decades since that day, and that mistake, and that new rule, and he's since passed. It's a lesson I'll never forget.
---
Programming projects get a folder on C:\, and I copy the .gitignore from y last project to exclude a ton of crud from the repo. Everything gets pushed to github, private or public depending on the nature of the code.
---
Additionally I back up everything to backblaze because it's saved my bacon a few times already.
I live in /home everywhere I can. Where home is, is a symlink depending on the OS.
I live in /usr/local (FreeBSD)
I used to live in /opt (SCO and Debian and OSX)
I used to live in /usr/local (OSX, Macports and HomeBrew)
I now live in /opt (Homebrew) and some of /usr/local (OSX) with minimal hand edits. Its better to let the pkg management run things
I now live in /tank (ZFS) and /data -> /tank (all OS I can, not OSX)
I now live in ~/Documents/<sub> with symlinks (OSX)
I try very very hard not to mess with /etc in odd ways (OSX, FreeBSD)
I accept limited rights to edit things in /usr/local/etc has to be managed by git, or other ways to keep configurations off the host in case I have to re-create.
I do ZFS snapshots over /data/tank and archive on an idle removable HDD, or replicate via snapshot increments to other hosts.
BSD quotas are too painful, I self police to lie under 10% free as much as possible.
When I install an OS by hand I try to make the "root" disk be at least a mirror. I try to make /data be at least raidz1 but preferrably raidz2
I believe in the power of 3-2-1 (3 copies of everything, two different forms, 1 offline)
I use /.../YYYY/... to move older things into a natural date hierarchy. I still believe in the power of limiting the number of file objects per directory, and keeping directory chains short, and primary direct objects as small as possible, so YYYY/MM/DD forms are natural to me. If I have deep high filecount data which can't do this I shard on hex 2-3 hex elements per subdir, it usually keeps things within sane bounds. Terminal file objects keep their true name. It means I may have YYYY/MM/DD/YYYY-MM-DD.json form data or /AB/CD/E/ABCDE.hex form data. Tant pis
We may be moving back to multiple parallel competing binary architectures (Arm, Intel) in our daily lives. NFS has a concept of interpolated ${HOSTARCH} variables in the symlink name which is increadibly powerful if you want to have a single NFS shared filesystem including system binaries, but have to manage competing binarch architectures. (the symlink literally has the ${string} but shell glob expands it at runtime to the specific architecture) -This is a trick from SunOS in the 68xxxx -> Sparc -> Intel days
I live in /usr/local (FreeBSD)
I used to live in /opt (SCO and Debian and OSX)
I used to live in /usr/local (OSX, Macports and HomeBrew)
I now live in /opt (Homebrew) and some of /usr/local (OSX) with minimal hand edits. Its better to let the pkg management run things
I now live in /tank (ZFS) and /data -> /tank (all OS I can, not OSX)
I now live in ~/Documents/<sub> with symlinks (OSX)
I try very very hard not to mess with /etc in odd ways (OSX, FreeBSD)
I accept limited rights to edit things in /usr/local/etc has to be managed by git, or other ways to keep configurations off the host in case I have to re-create.
I do ZFS snapshots over /data/tank and archive on an idle removable HDD, or replicate via snapshot increments to other hosts.
BSD quotas are too painful, I self police to lie under 10% free as much as possible.
When I install an OS by hand I try to make the "root" disk be at least a mirror. I try to make /data be at least raidz1 but preferrably raidz2
I believe in the power of 3-2-1 (3 copies of everything, two different forms, 1 offline)
I use /.../YYYY/... to move older things into a natural date hierarchy. I still believe in the power of limiting the number of file objects per directory, and keeping directory chains short, and primary direct objects as small as possible, so YYYY/MM/DD forms are natural to me. If I have deep high filecount data which can't do this I shard on hex 2-3 hex elements per subdir, it usually keeps things within sane bounds. Terminal file objects keep their true name. It means I may have YYYY/MM/DD/YYYY-MM-DD.json form data or /AB/CD/E/ABCDE.hex form data. Tant pis
We may be moving back to multiple parallel competing binary architectures (Arm, Intel) in our daily lives. NFS has a concept of interpolated ${HOSTARCH} variables in the symlink name which is increadibly powerful if you want to have a single NFS shared filesystem including system binaries, but have to manage competing binarch architectures. (the symlink literally has the ${string} but shell glob expands it at runtime to the specific architecture) -This is a trick from SunOS in the 68xxxx -> Sparc -> Intel days