Better hope you didn't have a rename in progress with the old name removed without the new name in place. Or a directory entry written pointing to a FAT chain not yet committed to the FAT.
Yes, soft updates style write ordering can help with some of the issues, but the Linux driver doesn't do that. And some of the issues are essentially unavoidable, requiring a a full fsck on each unclean shutdown.
I don't know how Linux driver updates FAT, but if it doesn't do it the way DOS did, then it's a bug that puts data at risk.
1) Allocate space in FAT#2, 2) Write data in file, 3) Allocate space in FAT#1, 4) Update directory entry (file size), 5) Update free space count.
Rename in FAT is an atomic operation. Overwrite old name with new name in the directory entry, which is just 1 sector write (or 2 if it has a long file name too).
No, the VFAT driver doesn't do anything even slightly resembling that.
In general "what DOS did" doesn't cut for a modern system with page and dentry caches and multiple tasks accessing the filesystem without completely horrible performance. I would be really surprised if Windows handled all those cases right with disk caching enabled.
While rename can be atomic in some cases, it cannot be in the case of cross directory renames or when the new filename doesn't fit in the existing directory sector.
> No, the VFAT driver doesn't do anything even slightly resembling that.
Which driver? DOS? FreeDOS? Linux? Did you study any of them?
> While rename can be atomic in some cases, it cannot be in the case of cross directory renames or when the new filename doesn't fit in the existing directory sector.
That's a "move". Yes, you would need to write 2-6 sectors in that case.
For short filenames, the new filename can't not fit the directory cluster, because short file names are fixed 8.3 characters, pre-allocated. A long file name can occupy up to 10 consecutive directory entries out of the 16 fixed entries each directory sector (512B) has. So, an in-place rename of a LFN can write 2 sectors maximum (or 1KB).
Considering that all current drives use 4KB sectors at least (a lot larger if you consider the erase block of a SSD) the rename opearation is still atomic in 99% of cases. Only one physical sector is written.
The most complicated rename operation would be if the LFN needs an extra cluster for the directory, or is shorter and one cluster is freed. In that case, there are usually 2 more 1-sector writes to the FAT tables.
Edit: I corrected some sector vs. cluster confusion.
I've also tried Gemini 3 for Clues by Sam and it can do really well, have not seen it make a single mistake even for Hard and Tricky ones. Haven't run it on too many puzzles though.
AFAIK Finland always had more separated sauna culture. They have so many saunas that you specifically pick when you want to go to mixed sauna.
In Germany or parts of eastern europe saunas are popular but there are not that many of them so they end up mixed gender. Also everybody is going to saunas in Finland where as in Germany its much more thing for "fans" or "experienced" sauna goers that maybe accept it as part of the whole thing.
USB HID actually works pretty much how you describe, for instance a Physical Descriptor can contain metadata about which body part a button/control is supposed to be used with.
It's extremely complicated however (like many things USB), which is probably why everything just emulates an XBox 360 controller like you said.
It's related to XInput making that easier option on Windows, from my understanding.
Especially if you supported both XBox and Windows.
So the only complex HID game controllers are for very much enthusiast setups, which are rare enough to trip things like absurd assumptions in HID drivers in some systems (the joystick+throttle I have used to break linux HID driver because someone decided to statically allocate possible amounts of joystick buttons per device...)
It'd be interesting to see a setup where a Linux-capable SoC would run the Arduino application on a isolated CPU core with no interrupts handled, so you'd still have real-time guarantee for the Arduino app
It runs the Arduino app on a separate mcu stm32l4 I think. So you have the realtime as well, but what you describe is already possible with the pi and asymmetric multiprocessing using openamp and zephyr.
For handhelds the temperature of the device's case is one factor as well when deciding the thermal limits (so you don't burn the user's hands) - less of a problem on laptops.
Ya that's what I'm hoping, because I've been blasted for a second or two here and there. I guess I could put a CD next to it and see if it crackles haha. But I'll probably just recycle it and move on.
reply