hi @Retired_mod  thanks for the reply. I'm aware of the possibility to perform checks and error handling to handle such situation. However, this is not optimal:

• Perform checks on top of a file and then writing it means reading it 2 times. So a flow with this kind of approach is 2 times slower and more expensive. Assuming that errors are "rare", a fix-after-error approach is more preferrable and easier to handle. 
• As we saw, COPY INTO will fail the full run in case 1 row in 1 file is malformed. Spark standard behavior is to fill up with nulls missing values/fields/lines etc, so a file that underwent some random truncation or contamination (or even a file truncated due to a IO error) will be read smoothly, and only a schema error is thrown, which would make a full run fail with very little log.

This issue automatically implies that a CSV can **never** be considered corrupted, as by definition is always readable. I would suggest to throw a warning in case "ignoreCorruptFiles" is enabled with CSVs, at least.

An alternative approach could be to deal the malformed rows with columnNameOfCorruptRecord . I didn't test it with COPY INTO, but as an approach I consider it very intrusive, as it introduces a new element in the schema and a full new flow to deal with them, whereas a manual or custom fix-after-error approach (again, given that we expect them to be very rare) would be more easily maintainable.

TL;DR a sort of ignoreMalformedFiles option with a meaning log info would save the situation in case COPY INTO is used with CSVs. This would allow the query to run over multiple files, and to skip schema unexpected files, which can be dealt and fix later.
Is there something similar implemented or planned?