linkedin / cassette Goto Github PK

NSUnarhiver unarchiveObjectWithData: is deprecated for
macosx-10.14 and ios 12.0

+ (nullable id)unarchiveObjectWithData:(NSData *)data API_DEPRECATED("Use +unarchivedObjectOfClass:fromData:error: instead", macosx(10.2,10.14), ios(2.0,12.0), watchos(2.0,5.0), tvos(9.0,12.0));

This is way only way I have found that works to do the same thing without the deprecated methods:

NSKeyedUnarchiver *unarchiver = [[NSKeyedUnarchiver alloc] initForReadingFromData:data error:nil];
[unarchiver setRequiresSecureCoding:NO];
CustomObject *object = [unarchiver decodeObjectForKey:NSKeyedArchiveRootObjectKey];

https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html

CASQueueFile writes its header to a a temporary commitFile with comments suggesting it should try and recover from failure when updating the metadata header.

This logic does not exist in the Java implementation of tape.

Worse yet, the Objective-C implementation does not actually recover from failure; it silently discards the queue file entirely and pretends like the queue was empty.

Probably this logic should just be deleted. Either we assume the OS writes the header atomically (in which case we don't need the temporary commitFile), or we need to write the entire queue (header and data) to a temporary file, then rename the temporary file over the real file.

the size of the database file maxes out at 4.26gb or roughtly 4,294,967,295 bytes because of storing _fileLength as unsigned int

e.g. writeData is deprecated. https://developer.apple.com/documentation/foundation/nsfilehandle/1410936-writedata?language=objc

[fileManager fileExistsAtPath:path] is returning true when a user provides a directory (in CASQueueFile.m). The assumption made by the code that path is a file. We should signal an error instead.

If we want the library to not be involved with folder management, file management, and want to require users to create intermediary directories themselves, having the relativePath option no longer makes sense.

Instead of writing to the main file, we should create a backup, write to it and then copy it over.

In the following circumstances:

• when expanding the database file during an add, and
• when an existing entry is wrapped around the end of the database file (since this is a ring buffer)

We erase the old wrapped tail, prior to updating the database header.
https://github.com/linkedin/cassette/blob/master/Cassette/CASQueueFile.m#L453

        [self ringEraseAtPosition:QueueFileHeaderLength length:count];

Although the window is small, if a crash occurs during this period it will result in corrupted data.

This solution should be simple, removing the line in question is most likely all we need