Glo Glo and Win 8.1

[Ripplinger]

I am very careful about always ejecting all devices and flash drives, and then double-checking a light isn't still glowing anywhere that might indicate writing might still be happening, and even taking Windows Explorer off the device or drive before I actually pull it out.

It seems to happen more when you haven't used a reader or drive in awhile, like Windows will always insist on checking it at that point.

If ever once an error was actually found, I might be more willing to put up with the Windows nagging, but never, ever, has that happened. Not once. If I suspect a problem or something seems off, I could still manually run a check whenever I wanted and gladly be rid of Windows constantly nagging me.

[davidfor]

Originally Posted by eschwartz

davidfor, I have the exact same experience as you, except Windows keeps bothering me. These days I don't bother with checking for errors and I don't always bother to use Eject, but I did try most thoroughly back when I still cared.

It happens on most of my flash storage devices, and it does not matter which computer I use. Accoring to your logic, all my flashdrives, and my Kindle, have failing memory? Of course, I checked with linux tools and that doesn't seem to be the case...
I believe the common factor is the OS from Redmond.

Actually, my logic was based on an error. I was thinking BobC had a Glo HD, not a Glo. If he had a Glo HD, it would be a brand new device, and if has any weird behaviour, it might be a hardware issue and hence faulty. If I suspected that from something I had recently bought, I would exchanging it. You should also not I suggested to check with other machines. That was to eliminate the possibility that

As to the rest, how sure are you that the other OSes are not messing up? All they have to do is not clear the dirty bit and Windows will think it the filesystem is dirty and needs to be checked. Windows is probably being over protective, but, as it has found and fixed problems with different USB storage over the years, I'm going to keep letting Windows fix the problem. And of course, if I didn't ejected safely, I would assume that the dirty bit was set and that Windows would complain. And if the other OSes didn't complain, I would be concerned they weren't checking properly.

[eschwartz]

No other OSes will even notice the dirty bit. They don't create it, they don't know how to find it, they don't use it, they don't delete it.

I don't worry my other OSes are messing up, but if the world would move on to a modern fs as the default cross-platform fs, then maybe we could use something like ext4.

linux will automatically fsck filesystems at regular intervals. Windows instead decides to warn you with angry popups about nothing.
Most of the times when I boot up, I get bootup logs telling me that orphaned inodes are being cleared up. That would be fsck at work. I don't have to do anything (it is a kernel/initramfs default) and it happens quite fast (seconds) on my nice modern fs.

I have nothing wrong on principle with telling the user his/her fs has a corruption issue, but Windows freaking out when a drive is not unmounted via the designated flush-data-and-unmount feature is unacceptable. It is just as effective and only a little more logical than warning about possible corruption as a Tuesday special.
By which I mean to say, naturally if you demand a filesystem check at random intervals it will sometimes pay off. But the dirty bit doesn't really help that process.
And it is chkdsk (fsck for Windows) that has fixed problems, not the dirty bit.

[PeterT]

I give up. Obvi0suly we are talking here with the ultimate expert on FAT file systems; one who understands the exact nuance of what does and dnes not constitutes a possib;y damaged file system.

[eschwartz]

I do know that being marked with the Windows dirty bit does not constitute a damaged filesystem.

I also know that Mac OSX and linux users never have to worry about that particular type of obtuse warning, and at the same time our removable drives never languish unknowingly corrupted as a result.

[PeterT]

Remember, a file system is a complex entity, and to ensure total data integrity is a major challenge. Not only is there a need to write the data, but also the directory entries, and updates to the allocation tables that keeps track of what clusters of the media have been written too.

To safeguard this multiple writing operation, the dirty bit would be written, followed by ALL the required data writes including the multiple copies of the allocation table, followed by once it was known the data had been flushed to the actual disk, the dirty bit would be cleared.

While it is possible that some hypothetical file system would forgo some of these steps, the use of the dirty bit is an attempt to ensure that full consistency exists between all the structures that comprise a file system.

I don't care WHAT O/S or file system is in use; it is impossible for their to be a guarantee on the consistency of these data structures without some form of dirty bit; especially when some of the structures are stored in more than one location.

[eschwartz]

Alternatively, engineer the filesystem so that doing a full consistency check can be completed with a minimum of fuss, and do that automatically. It isn't just a hypothetical thing, there are filesystems that do that.

But regardless, any "attempt to ensure that full consistency exists" which causes exorbitant frustration to users is going to end up ignored and in the worst case, disabled -- which means even the hypothetical filesystems have the advantage.

For a supposedly user-friendly OS, it is surprising how malignant MS has made this feature.

[BobC]

All this sounds reasonable except that when I connect the Glo to my Win 8.1 machine it objects, but if I connect it to my XP machine it doesn't. If there was some "stuck bit" then surely it should show up on both.

The other point is that when I connect the Glo it isn't as though it is actually a drive - an area of memory is being exposed as a drive by the Linux USB Mass Storage Gadget running on the Glo. The file system exposed will be re-created with each reboot of the Glo so any foolishness with "stuck bits" should disappear.

Whatever is happening XP doesn't know about it 8.1 does.

BobC

[PeterT]

Bobc, the storage being shown on your PC from the Kobo is actually a physical partition of the internal SD card in the Kobo; its NOT RAM that is refreshed on reboot.

[BobC]

Originally Posted by PeterT

Bobc, the storage being shown on your PC from the Kobo is actually a physical partition of the internal SD card in the Kobo; its NOT RAM that is refreshed on reboot.

I didn't think it was RAM - I was reading the stuff on the USB Mass Storage Linux Gadget which I understand provides the USB interface. As this is a service that runs on bootup of the Glo and spoofs what looks like a FAT Filesystem from an area of memory (albeit derived from the SD card) I understand that this will re-create the virtual file system on each re-boot. Somewhere I'm sure when poking about with various tools I saw the "drive" shown as a Linux mass Storage Gadget, which is why I reasoned as above. As I mentioned though the issue only arises under Win 8.1 .

BobC

[eschwartz]

I don't know how the Kobos handle it, but on Kindles the external storage is a separate partition that is exported directly (as in, the partition itself) and mounted to the computer.

I would think the Kobos were doing essentially the same thing.


As for the Win8-only thing... I don't believe Windows XP actually did any complaining. WinXP is pretty old though.
I am pretty sure it was Vista that first threw hissy fits.

[BobC]

Originally Posted by eschwartz

I don't know how the Kobos handle it, but on Kindles the external storage is a separate partition that is exported directly (as in, the partition itself) and mounted to the computer.

I would think the Kobos were doing essentially the same thing.


As for the Win8-only thing... I don't believe Windows XP actually did any complaining. WinXP is pretty old though.
I am pretty sure it was Vista that first threw hissy fits.

@eshwartz
I may have made a mistake with my assumption that Kobo used the Mass Storage Gadget approach to exporting the filesystem. I've been trawling through the stuff I have on my new computer and there is no sign of a MSG device being connected to it - so it must have been one of my other readers that did this (I've never connected them to this PC). I'll have to do a brain reset on that :-)

It was your post #3 that led me to believe the issue manifested itself on ALL versions of Windows so I looked for a non-OS version specific explanation. With that out of the way I think it's clear that it's Win 8.1 (and perhaps other earlier versions) that are throwing up this "error" but are unable to clear it.

As for using a hex editor to clear the bit - I CBA. I once wrote a raw disk editor to recover some deleted files on a CDOS disk by manually editing the FAT but that's years back now and I'd rather just ignore the error, which might reappear anyway. Back then (pre-Internet) you couldn't just download tools like that for an obscure O.S. you had to roll your own.


BobC

[davidfor]

Yes, there is a USB gadget of some sort loaded on the Kobo. All it seems to be doing is presenting the data partition to the PC. I suppose it must be virtualizing the partition table or something because the PC just sees the one partition.

As to the problem, if it is only the one Win8 machine, then maybe it is remembering something. Something I have done in the past to solve some connection problems for my Kobo ereaders is use USBDeview to delete the device. On the next connection, the device was reinstalled and everything was OK.

[BobC]

Originally Posted by davidfor

As to the problem, if it is only the one Win8 machine, then maybe it is remembering something. Something I have done in the past to solve some connection problems for my Kobo ereaders is use USBDeview to delete the device. On the next connection, the device was reinstalled and everything was OK.

Now we've got somewhere - I uninstalled the device using USBDeview then reconnected - it came up with the error. This time when I asked it to scan and repair it did so and reported no errors. However when I next connected no problem - it doesn't complain any more.

Looks like there is a solution lurking in there somewhere, previously when I scanned and repaired it didn't solve the problem.

Thanks for putting me on the right track.

BobC