|
Running SQL Remote 8.0.3 with the FILE message type I would like to modify the message file names that are generated by SQL Remote. The main reason is to prevent "suspicious" file extensions (as is possible since V 10 with the "invalid_extensions" option). So when the consolidated database creates message files like "remote1.exd", "remote1.exe", "remote1.exf", chances are high that the second file might not get transferred to the client because of the suspicious EXE extension. In our case this is a problem, as we use HTTPS to do the real file transfer, and files with extensions like "cs", "exe", vbs" (that will occur over the time) will block the transfer. Obviously the underlying protocol (WinINet) seems to prevent such file downloads and uploads. Therefore I'd like to rename each message file by adding a "neutral" extension like ".dat". In the above case, the files would then be named "remote1.exd.dat", "remote1.exe.dat"... This seems to work but I would like to know if there are any caveats or if it is alright to do so. Current test results: According to my tests, the message file name seems to be of minor importance to SQL Remote: When several files are in the message queue, SQL Remote will open them in file name order (so "remote1.exd" will be received before "remote1.exe"). But the guaranteed message tracking system makes sure messages are applied in the correct order. So a "wrong file name" might just disturb the order in which files are received but not the order in which messages are applied. Furthermore, just adding an second extension won't change the file order, so even the message receiving phase should be o.k. |
|
Answer as given by Reg Domaratzki [Sybase iAnywhere] in the Replication newsgroup:
And my response:
|
Just to clarify: The renaming would take part outside of SQL Remote. The "surrounding app" would rename the generated files before they get transferred.
How about just adding a fixed 4th letter in front of the current three letters of the extension? As in .Xexf, .Xexe etcetera.
@Breck: If the fime name as such is not relevant (that's what my question is about:) then your suggestion is a good one. I guess 4-character-long extensions are uncommon and as such not critical. However, as SQL Remote uses 1-3 characters, adding (or appending) a fixed character might lead to new problems, say when an uncritical "ls" extension would be renamed to "Xls" (if that is suspicious). So adding a digit might be less problematic.
@Breck: Besides my above remarks, I also thought about that suggestion: Our current client-side SQL Remote wrapper expects that the inbox only contains files with a file title that equals the consolidated publisher's name. So adding a character to the extension would be o.k. In contrast, adding an additional extension would turn the original extension into a part of the file title (from "cons" to "cons.exf") and as such would violate that constraint so I would first have to adapt all client software.