OpenSolaris as windows storage appliance: bulletproofing

Running OS snv_124 via EON, created a ZFS pool and dataset, set smbshare=guestok=true, browsed to the CIFS share from a Windows XP box, and ran some tests.

Copy two files to share by drag-and-drop in Finder, yank power to the server before second file finishes copying. After powering server back up, both files are there with correct (full) file size. The only hint that the second file might not be complete/correct is the timestamp, which was left at time of copy rather than time of original file. Of course, checksums differ between original copy on Windows box and the unfinished copy on server.








I understand that this behaviour is not OpenSolaris' fault. However it is undesireable: it is non-transactional, and a form of data corruption. If a connection to server is lost during a bulk transfer over CIFS, the user has to hunt down which file(s) might be incomplete and manually check/delete them. A backup solution which compares file size and date might fail, it would need to checksum all files or have "date inversion -> recopy" logic (and I do not know whether the timestamp is 100% reliable as an indicator of incomplete write) If a user is prompted "do you wish to overwrite file size 123456 with older version size 123456" they will likely decline, leaving the copy on server incorrect.

I also understand that this situation can be avoided: only write files using a utility which write to tmp file then renames, for instance. However it would increase the value of OS as a storage appliance to be as bulletproof as possible to *any* use by Windows users.

Ideally, incomplete files should never have full file size. This would allow any dumb or manual backup process to detect the incompleteness. For instance, right click->properties on a parent folder would show a difference in size vs original, indicating that the data within is not complete. Basic filesize comparison would trigger a recopy without relying on more esoteric properties such as timestamp.

Is there any currently available method to mitigate this from the OS side? eg

1. Making sure that file sizes will always reflect the amount of data written
2. CIFS option to implement file writes as tmp->rename... this way incomplete files appear to be missing (although without 1. some methods, eg checking size of parent folder, would still mislead users)
3. Some method to remove file completely if write did not complete, perhaps relying on ZIL mechanism so it can be applied at startup after server crash.

Failing that, is there any one-time configuration to a Windows machine to change any of its behaviours to increase robustness?

I am not familiar with the details of CIFS and how various versions of windows handle file copy/move. It is likely that the suggestions above are impossible or don't make sense. However finding a way to make sure that incomplete file/batch copies are immediately detectable would make OS more robust as a storage appliance.

Pointers from those in the know about what can and can't currently be done, what a future solution might look like, or why the above is totally wrong-headed are appreciated.