FTP: refuse to delete, rename or overwrite the mounted image

[iTechMedic]

One commit. The web UI has always refused to delete the image the host has mounted. FTP had no such guard, so the same card could be broken over FTP in a way the browser would not allow, and a user reported the device locking up after the image file stopped existing.

Three FTP paths could do it:

• DELE unlinks the mounted image, leaving the gadget reading storage with no directory entry while the host keeps issuing READ(10).
• RNTO moves it out from under the mount just as effectively, and renaming something else onto it destroys it.
• STOR opens FA_CREATE_ALWAYS, which truncates. Uploading over the mounted image is the worst of the three, because the directory entry survives and nothing looks wrong until a read comes back short.

The comparison is the whole difficulty here, and it is not obvious. The same file reaches the guard spelled three different ways:

• 1:/x.cue is what SCSITBService::GetCurrentCDPath() always reports.
• 1://x.cue is what RealPath() produces, because it formats "%s/%s" onto m_CurrentPath, and that is "1:/" for the whole session whenever the worker auto enters the images partition on connect, which it does for every client that does not CWD somewhere first.
• 1:x.cue is what FTPPathToFatFsPath() produces, because it consumes the separator after the volume when converting an absolute FTP path and never restores it.

FatFs resolves all three to the same file, since a drive relative path is taken against that volume's current directory, which is its root. So every spelling works for f_open, f_unlink and f_rename, and only a string comparison can tell them apart. A guard that compares them naively is silently inert for the most ordinary case there is, and appears to work the moment the client happens to CWD first. I know because mine was, twice.

Paths are now normalised before comparing, case insensitively because FAT is.

That comparison lives in its own header rather than in the worker because ftpworker.cpp cannot be compiled into the host suite, it needs the socket stack, and a guard nothing can test is a guard that quietly stops working. test_ftppaths.cpp asserts every spelling the worker actually produces, and the negative cases too: a prefix, a deeper path, or a same named file on 0: must not match, because a guard that over refuses is its own bug.

Hardware tested: delete, rename and upload over the mounted image are all refused over FTP, and the same operations on any other image still work.

Host suite 151/151.

[iTechMedic]

Superseded by #238, which combines this with the rest of the batch into a single branch. Same commits, no changes dropped. Closing this one.