dcpomatic/src/lib/file_group.cc, branch 2623-add-windowsDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=2623-add-windows2023-10-08T23:21:22ZUse dcp::filesystem to wrap filesystem calls and fix_long_path2023-10-08T23:21:22ZCarl Hetheringtoncth@carlh.net2023-10-06T00:37:16Zurn:sha1:f0f4dd5e6b6ed5e50d0444a4de3b2a13156edf64
anything that is passed to read_file() from libcxml.
This should fix #2623 and other similar problems.
Return AVERROR_EOF from the avio_read method when appropriate.2022-11-25T23:09:27ZCarl Hetheringtoncth@carlh.net2022-10-01T18:11:40Zurn:sha1:bc6fd8c020ad27c86c463876f76c8add042cb660Use dcp::File in DCP-o-matic (#2231).2022-05-05T21:38:41ZCarl Hetheringtoncth@carlh.net2022-04-16T20:20:54Zurn:sha1:8a8c977c12fc65f1f50ea05099387e0fc8840e7dC++11 tidying.2021-04-30T23:31:35ZCarl Hetheringtoncth@carlh.net2021-04-30T23:31:35Zurn:sha1:8963f0007af1a312017b9627c18b82ec2a577591Fix over-read behaviour of FileGroup to be the same on all platforms.2020-11-28T19:58:56ZCarl Hetheringtoncth@carlh.net2020-11-27T22:30:13Zurn:sha1:cf26869c2789b7ecf91e486fc3c7bf271276a592
Instead of relying on the operating system's behaviour when seeking
off the end of a file, keep our own _position. This normalises
the behaviour between POSIX and Windows.
Fix the behaviour of FileGroup when seeking too far.2020-11-24T22:01:04ZCarl Hetheringtoncth@carlh.net2020-11-24T22:01:04Zurn:sha1:8a1da1da65ba0e6a6fb915c73ff6e6a81da349f2
Previously, if you did a seek off the end of the file group,
the seek would return an error.
This is not what fseek() does; it returns no error, and preserves
the file pointer (returned by ftell()) as if the seek had been
successful. fread()s after a too-far seek return no data, of
course.
Parsing some files (the example used to find the bug was a
H264 MP4) involves a seek which is to the byte after the end
of the mp4 file. If this fails the whole header parsing fails
and DCP-o-matic refuses to use the file.
Fix errors when over-reading a "large" amount from FileGroups on2020-10-13T16:51:11ZCarl Hetheringtoncth@carlh.net2020-10-06T23:02:47Zurn:sha1:e5277d4042b896c4b50c694fba0f1afb47337f45
Windows. I haven't been able to find any conclusive explanation for
why this stuff happens;
https://stackoverflow.com/questions/7241168/safe-maximum-number-of-records-read-by-fread
is one possible lead.
Improve OpenFileError so that it doesn't say "opening for read"2019-09-29T21:28:57ZCarl Hetheringtoncth@carlh.net2019-09-29T21:28:57Zurn:sha1:ab0e8cdcafdcb83096012380f674b8280474e851
in one case where it should say "opening for read/write".
Also add some unit tests for ReelWriter.
Let's not accept EAGAIN until we're sure it's possible.2018-12-19T22:24:35ZCarl Hetheringtoncth@carlh.net2018-12-19T22:24:35Zurn:sha1:d60fd90a6e13c727a05b629c8c4b93d4bf3b717bHopefully fix error handling (including EAGAIN) in FileGroup.2018-12-19T22:16:32ZCarl Hetheringtoncth@carlh.net2018-12-19T22:15:34Zurn:sha1:7c3f9fd51051330c8fc58c298b907222d734fa31