User Agent: Mozilla/5.0 (Windows NT 6.0; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160604131506 Steps to reproduce: beware of 0-length-files in windows and dos. no punctuation is allowed in NTFS. that goes for tb also. get the latest NTFS spec if necessary. bad ntfs driver and API. Actual results: fs corruption Expected results: Win32 and .net API should be used for creating files.
some punctuation is allowed, but it is causing problems with what is used by mozilla.org - just have a talk with microsoft directly
Jim, this bug report is very vague. Have you identified a specific problem that needs to be resolved, or is this more of a request to audit some class of filesystem interactions? If so, do you have a link or other detailed explanation of the threat that we should be protecting against?
I had a lot of strange happenings a short while back. if this is in error, please disregard. sometimes I do get wrong information. as for NTFS, ReFS (file servers and win8-10), DOS, FAT12/16/32/VFAT/FAT64/exFAT, these versions of FAT cannot handle most kinds of punctuation, it corrupts the filesystem. the WIN32 API such as CreateFile() may allow such filenames to pass through it but it also does not check filepath length (for instance, in the MSDN, MAX_PATH=260 in file API stuff is mentioned as use for maximum path length, but NTFS maximum path length is 255 and this needs to be taken into consideration. as for creating or deleting a 0-length file, I thought, "how can this be a problem?" but I was convinced somehow, and while I am unsure about this and whether it's still a problem of whether it corrupts the fs or not, (and it shouldn't), I would have a talk with microsoft about that. it's really easy to create a 0-len file, just create a file with the always bit turned on, and then close the file and forget to delete it. on a 512-byte-sector disk in *nix it takes up one inode of space. on windows it takes up a whole cluster, which can be up to 65536 (is that bytes or sectors?). on an SSD it's minimum 4K for the 0-length file. I see no programmatical reason why this should be an fs corruption problem since when the representation of an uinteger64 sort of file size is used, it is not 1-based like BASIC, it is 0-based like in C and asm. sorry for being so vague. let's just assume that the 0-length file is not such a problem. I noticed that tb no longer uses fs-corrupting symbols in the filenames for its IMAP email files in local storage. this is good.
ok. I don't think there's a specific engineering action we can take at this time, so I'm going to resolve this. But if you see Firefox/Thunderbird creating bad files in a specific situation, please file a bug with the details so we can review it!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.