Folks who know "rsync -F" because they already use it -- am I right in thinking that it adds these behaviours to a sync:
- recursively look for .rsync-filter files in every directory in the copy source, including the top-level
- apply the filters they each contain to the directory and subdirectories rooted at the same level that each file was found
- exclude those .rsync-filter files from being copied to the destination
Is that right? #rsync #sync #data #sysadmin #filesystem #filesystems
Which in turn then prompts the question of whether one with suitable chicanery could set it up as a correct i-node which fsck would consider allocated, but that would be unfixable.
Presumably the reference counting checks would detect it as an an orphan, but putting a directory entry referencing it in lost+found would not work.
Assuming that the reference counting pass does not also have a < ROOTINO short-circuit in the code too. (-:
The same thought occurred to me. There have been cute tricks like that played. I've even played some of them on other systems.
But as far as I know that first entry in the i-node table was just unused.
I wonder whether fsck even checked it. Modern FreeBSD fsck_ffs does, but that's a very different beast.
Off By One Error in your post on this. (-:
Since 0 means a free directory entry, that's only 65535 i-nodes.
Mind you, at 8 i-nodes per block, you'd come close to the size of some contemporary discs with a maximally sized i-node table.
Yes. Berkeley FFS broke things up into cylinder groups and had an allocation policy of putting various things in the same CG and other things not, because much the same idea was also useful for reducing seeks on discs.
(Even OS/2 got in on the act. (-: Its FAT filesytem driver put the extended attributes record for every file in front of the file data where it could. Which was why it was a bad idea to defragment the "EA DATA. SF" file so that it ended up stuffed all at the start of the volume.)
And the elevator algorithm in the block cache would at least make the tape do straight runs in one direction and then rewind, where it could.
Putting filesystem *and* swap on tape boggles the mind, though. (-:
Making openat(2) and friends more useful in practice https://www.undeadly.org/cgi?action=article;sid=20250529080623 #openbsd #openat #open #filesystems #security #development #unveil - now also with regression tests, more discussions on tech@
There seem to be no answers matching "back". Both options match "up".
I think that you've overlooked an even more important poll that might be the shibboleth of our time: Does one go up and down a tree? Or does one go back and forth a tree?
Has the tree been chopped down?
(-:
PSA: If your software intended for #Linux cannot deal with filenames that contain
- spaces
- command line flags
- non-ASCII
- newlines
- control characters
- invalid UTF-8
then YOUR SOFTWARE IS WRONG AND BAD
and when it breaks IT IS YOUR FAULT and you DO NOT GET TO BLAME THE PEOPLE WHO NAMED THE FILES
This blog https://0pointer.de/blog/projects/locking.html draws a pretty bad situation about file #locking on #Linux #filesystems. But it is from 2010 - does anybody know if the situation has technically improved since than?
BtrFS completely sucks & i shall never again make the error of using it instead of ext4. 😡
#BtrFS #ext4 #linux #filesystems #ArchInstall #ArchLinux #VM
#Linus #Torvalds Expresses His Hatred For #CaseInsensitive #FileSystems - #Slashdot
" Dammit. Case sensitivity is a BUG. The fact that filesystem people *still* think it's a feature, I cannot understand. It's like they revere the old FAT filesystem _so_ much that they have to recreate it — badly."
I do like his direct approach! Even if I grew on #AmigaFFS which was "almost case-insensitive"
https://linux.slashdot.org/story/25/04/27/0547245/linus-torvalds-expresses-his-hatred-for-case-insensitive-file-systems
"The Impact of Microsoft’s ReFS on DFIR" -> comparing NTFS evidences with ReFS. What stays, what changes and what will be gone. Recommended read! https://medium.com/@mathias.fuchs/the-impact-of-microsofts-refs-on-dfir-cdb78f401bfd #DFIR #ReFS #NTFS #filesystems
Seeing this toot https://mstdn.social/@elfin/114371800122912697
Reminded me of the time at BNR their SUNOS filesystems suddenly had '/' in filenames due to a buggy MAC link. Yes it took fsdb to fix the problem.
An Intro to DeepSeek's Distributed File System
https://maknee.github.io/blog/2025/3FS-Performance-Journal-1/
#HackerNews #DeepSeek #Distributed #File #System #Intro #FileSystems #TechInnovation #DataStorage
Unix files have (at least) two sizes
https://utcc.utoronto.ca/~cks/space/blog/unix/UnixFilesTwoSizes
#HackerNews #UnixFiles #UnixSizes #FileSystems #TechBlog #HackerNews
TIL that xfs has supported copy-on-write reflink copies for years (Kernel 4.9.1 in 2017!), where as zfs only got it last year (and it is not considered stable!)
https://blogs.oracle.com/linux/post/xfs-data-block-sharing-reflink
🥴 Ah, the 2019 classic where we learned that file systems are apparently incapable of managing distributed storage—because who knew they weren't designed for it? But first, make sure you enable #JavaScript and #cookies, because reading this revelation requires a digital permission slip. 🍪🔑
https://dl.acm.org/doi/pdf/10.1145/3341301.3359656 #fileSystems #distributedStorage #techNews #digitalPermissions #HackerNews #ngated
File Systems Unfit as Distributed Storage Back Ends (2019)
https://dl.acm.org/doi/pdf/10.1145/3341301.3359656
#HackerNews #FileSystems #DistributedStorage #TechResearch #ACM2023 #StorageSolutions
[2022] OpenBSD transforms a bag of blocks into useful filesystems - Ken Westerback
💪 3FS: A high-performance distributed file system designed to address the challenges of AI training and inference workloads
