Нет, на самом деле это в Raring. Я столкнулся с той же проблемой дважды. Не удалось увидеть, что такое обновления, но все еще смогло установить его.
В моем последнем журнале apt сказано:
Log started: 2013-08-13 01:26:33
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 258136 files and directories currently installed.)
Preparing to replace libbamf3-1:amd64 0.4.0daily13.04.03-0ubuntu1 (using .../libbamf3-1_0.4.0daily13.06.19~13.04-0ubuntu1_amd64.deb) ...
Unpacking replacement libbamf3-1:amd64 ...
Preparing to replace bamfdaemon 0.4.0daily13.04.03-0ubuntu1 (using .../bamfdaemon_0.4.0daily13.06.19~13.04-0ubuntu1_amd64.deb) ...
Unpacking replacement bamfdaemon ...
Preparing to replace libdvdnav4:amd64 4.2.0+20130225-1 (using .../libdvdnav4_4.2.0+20130225-1ubuntu0.1_amd64.deb) ...
Unpacking replacement libdvdnav4:amd64 ...
Setting up bamfdaemon (0.4.0daily13.06.19~13.04-0ubuntu1) ...
Rebuilding /usr/share/applications/bamf-2.index...
Setting up libbamf3-1:amd64 (0.4.0daily13.06.19~13.04-0ubuntu1) ...
Setting up libdvdnav4:amd64 (4.2.0+20130225-1ubuntu0.1) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Log ended: 2013-08-13 01:26:35
Итак, по крайней мере, я вижу, что было установлено. .
UPDATE:
Ответ muru идеально подходит для размера файла, я здесь даю решение как самому самому самому самому директорию, а не просто файлу.
Нет такой вещи, поскольку файловая система обрабатывает папку как файл файлов, а ее предел - это вся файловая система.
Итак, в качестве обходного пути для вашей проблемы вы можете создать трюк виртуальную файловую систему и смонтировать ее в определенном (пустом) каталоге.
создать точку монтирования виртуальной файловой системы для монтирования (~ / test for me)
mkdir ~/test
создать файл, полный / dev / zero, достаточно большой, чтобы максимальный размер, который вы хотите зарезервировать для виртуальной файловой системы (я делаю здесь для 1 МБ)
dd if=/dev/zero of=test.img bs=1024 count=0 seek=1024
форматирует этот файл с файловой системой ext4
mke2fs test.img
монтирует только что отформатированный дисковое пространство в каталоге, который вы создали как точку монтирования
mount -o loop test.img ~/test
Затем используйте этот каталог
Я бы сказал, что безопаснее проверять размер файла внутри java-программы.
Вы можете добавить к любому файлу, на который у вас есть доступ на запись, если в разделе достаточно места, поэтому вы не можете ограничить размер файла напрямую.
Единственное, о чем я могу думать, это создать раздел только для этого файла, поэтому размер файла будет ограничен размером раздела. Кроме того, если вы отформатируете раздел как FAT32, файл может иметь максимальный размер 4 гигабайта.
Не видя свой код, трудно определить, будет ли ваше приложение OOM или нет.
Обычно вы читаете управляемый фрагмент данных (скажем, 1 МБ) из сокета и записываете этот фрагмент данных непосредственно в файл. Таким образом, вы никогда не будете хранить больше, чем временный фрагмент в памяти в любой момент времени.
Обычно это выглядит так:
FileOutputStream fos = new FileOutputStream("receivedData");
InputStream is = clientSocket.getInputStream();
byte[] buffer = new byte[1024];
int read;
while((read = is.read(buffer)) != -1) {
fos.write(buffer);
};
Затем вы можете добавить счетчик к while, чтобы подсчитать, сколько байтов было записано в файл, и прекратить сокет, если он перейдет на заданную сумму или приблизится к потреблению всего доступного дискового пространства.