Revision history [back]

First of all: If found a seemingly similar question, but it seems to be about a completely different issue because the user over there used ext4.

The other day I left my Sony Xperia at home to record all the bad things our dog loves to do while we're away. I knew we'd be gone for hours, but I expected an operating system that runs cloud servers to handle possible problems with file size and/or memory issues. :p

The camera is configured to save recordings to my SD-card, which is almost empty but only FAT32.

When I came home, the camera had crashed. Sailfish gave me the opportunity to either wait or terminate the application. After having tried to let it "wait" a few times, I chose terminate and had a look at what damage had been done.

1. The video was there, but in /media/....../Videos/ instead of /media/....../Videos/Camera (maybe that's where it's stored temporarily during recording?)
2. The size of the video file was 4.294.967.295, which is only 1 byte away from the FAT32 limit. Most probably it was this file size limit that caused trouble, not anything else.
3. The video file was corrupted and refused to play in any player I know. I'm experimenting with untrunc currently to bring it back to life, but the file size makes it difficult.

While I'm aware that the file size limit as such is a law of nature and I'm responsible for the file system I use on my SD card, I consider it a bug if a camera application crashes instead of handling the situation gracefully. I also consider it a bug if the recorded video data is lost for the average user (although there's hope part of it can be restored).

I'd suggest that either the camera application should record chunks that are compatible with the file system (and stop only if there's no more space left on the device) or at least stop recording if necessary, allowing for the file headers etc. to be written. What it shouldn't do is crash and leave an unplayable mess.

First of all: If found a seemingly similar question, but it seems to be about a completely different issue because the user over there used ext4.

The other day I left my Sony Xperia at home to record all the bad things our dog loves to do while we're away. I knew we'd be gone for hours, but I expected an operating system that runs cloud servers to handle possible problems with file size and/or memory issues. :p

The camera is configured to save recordings to my SD-card, which is almost empty but only FAT32.

When I came home, the camera had crashed. Sailfish gave me the opportunity to either wait or terminate the application. After having tried to let it "wait" a few times, I chose terminate and had a look at what damage had been done.

1. The video was there, but in /media/....../Videos/ instead of /media/....../Videos/Camera (maybe that's where it's stored temporarily during recording?)
2. The size of the video file was 4.294.967.295, 4.294.967.295 bytes, which is only 1 byte away from the FAT32 limit. Most probably it was this file size limit that caused trouble, not anything else.
3. The video file was corrupted and refused to play in any player I know. I'm experimenting with untrunc currently to bring it back to life, but the file size makes it difficult.

While I'm aware that the file size limit as such is a law of nature and I'm responsible for the file system I use on my SD card, I consider it a bug if a camera application crashes instead of handling the situation gracefully. I also consider it a bug if the recorded video data is lost for the average user (although there's hope part of it can be restored).

I'd suggest that either the camera application should record chunks that are compatible with the file system (and stop only if there's no more space left on the device) or at least stop recording if necessary, allowing for the file headers etc. to be written. What it shouldn't do is crash and leave an unplayable mess.

First of all: If found a seemingly similar question, but it seems to be about a completely different issue because the user over there used ext4.

The other day I left my Sony Xperia at home to record all the bad things our dog loves to do while we're away. I knew we'd be gone for hours, but I expected an operating system that runs cloud servers to handle possible problems with file size and/or memory issues. :p

The camera is configured to save recordings to my SD-card, which is almost empty but only FAT32.

When I came home, the camera had crashed. Sailfish gave me the opportunity to either wait or terminate the application. After having tried to let it "wait" a few times, I chose terminate and had a look at what damage had been done.

1. The video was there, but in /media/....../Videos/ instead of /media/....../Videos/Camera (maybe that's where it's stored temporarily during recording?)
2. The size of the video file was 4.294.967.295 bytes, which is only 1 byte away from the FAT32 limit. Most probably it was this file size limit that caused trouble, not anything else.
3. The video file was corrupted and refused to play in any player I know. I'm experimenting with untrunc currently to bring it back to life, but the file size makes it difficult.

While I'm aware that the file size limit as such is a law of nature and I'm responsible for the file system I use on my SD card, I consider it a bug if a camera application crashes instead of handling the situation gracefully. I also consider it a bug if the recorded video data is lost for the average user (although there's hope part of it can be restored).

I'd suggest that either the camera application should record store chunks that are compatible with the file system (and stop only if there's no more space left on the device) or at least stop recording if necessary, allowing for the file headers etc. to be written. What it shouldn't do is crash and leave an unplayable mess.

First of all: If found a seemingly similar question, but it seems to be about a completely different issue because the user over there used ext4.

The other day I left my Sony Xperia (2.1.3.7) at home to record all the bad things our dog loves to do while we're away. I knew we'd be gone for hours, but I expected an operating system that runs cloud servers to handle possible problems with file size and/or memory issues. :p

The camera is configured to save recordings to my SD-card, which is almost empty but only FAT32.

When I came home, the camera had crashed. Sailfish gave me the opportunity to either wait or terminate the application. After having tried to let it "wait" a few times, I chose terminate and had a look at what damage had been done.

1. The video was there, but in /media/....../Videos/ instead of /media/....../Videos/Camera (maybe that's where it's stored temporarily during recording?)
2. The size of the video file was 4.294.967.295 bytes, which is only 1 byte away from the FAT32 limit. Most probably it was this file size limit that caused trouble, not anything else.
3. The video file was corrupted and refused to play in any player I know. I'm experimenting with untrunc currently to bring it back to life, but the file size makes it difficult.

While I'm aware that the file size limit as such is a law of nature and I'm responsible for the file system I use on my SD card, I consider it a bug if a camera application crashes instead of handling the situation gracefully. I also consider it a bug if the recorded video data is lost for the average user (although there's hope part of it can be restored).

I'd suggest that either the camera application should store chunks that are compatible with the file system (and stop only if there's no more space left on the device) or at least stop recording if necessary, allowing for the file headers etc. to be written. What it shouldn't do is crash and leave an unplayable mess.