Russian Qt Forum

Имеются ли в QT возможности создавать Hardlink?

Такой возможности не видел. Юзай QProcess + ln (Linux) или fsutil (Windows, NTFS)

Плохо. Прийдется делать свою системнозависимую реализацию.

извиняюсь за тупой вопрос - разве в винде есть хардлинки?

Есть на ntfs.

а у меня двухтонник говорит, что не знает ни каких "fsutil"

а насколько данный функционал вобще востребован?
я имею в виду поддержку симлинков под нтфс и хардлинков под никсы/свисту...

вот от символической ссылки на двухтоннике яб не отказался, ведь ярлыки - всего лишь этикетки. к ним нельзя обращаться как файлам/каталогам.

Симлинки меня не интересуют. Под NTFS можно создавать хардлинки. О симлинках я не говорил, для моей задачи они не годятся.
Если упрощенно, то задача такая:
1) Есть packages
2) package - набор файлов типичный объем 1GB (на самом деле есть еще некоторая метаинформация)
3) package инсталлируется - файлы распаковываются в определенную директорию(для каждого package в свою)
4) package может быть как независимый, так и update или add-on к уже существующему
5) Есть объекты ссылающиеся на данные именно конкретного package, а в случае если он update или add-on то на недостающие в нем данные родительских packages, но не на сами родительские packages!
6) Любой package, в том числе и родительский можно деинсталлировать(удалить), но это не должно привести к потерям данных для тех объектов которые ссылаются на дочерние packages
7) Необходимо избежать дублирование данных для дочерних packages(поскольку объемы достаточно большие).
8.) Упростить деинсталляцию package.
9) В процессе инсталляции package упростить обработку ошибок и откат.

собсна, почему я спрашиваю?
в венде, начиная с висты, появилась нативная поддержка симлинков и хардлинков (к сожалению, под 2к придётся пользоваться костылями). поддержку симлинков я уже реализовал в QFSFileengine, НО создал этим новую проблему - как теперь под вендой контейнеры должны себя вести для путей, содержащих "ненастоящие" линки (ака алиасы)?
чуть подробнее: допустим, имеются логические диски D: и E:, D:/E.lnk - алиас, ссылающийся на E:/ и D:/E - симлинка, ссылающаяся на E:/ :
получаем разное поведение, т.к. для нормальной работы алиасы необходимо резолвить отдельно. если пойти по существующему пути и резолвить алиасы "прозрачно" в файлэнджине, получаем оверхед, от которого невозможно избавиться без изменения поведения (как сейчас для *.lnk, ссылающихся на недоступные ресурсы). альтернатива - QAbstractFileEngineV2. для поддержки хардлинков вариант только один - QAbstractFileEngineV2.
но QAbstractFileEngineV2 - работа далеко на на пару вечеров...

по этим причинам идею я пока забросил, но могу возобновить работу, если данный функционал востребован не только мной.

Константин, Предлагаю тему разделить, чтобы не мешатся основному вопросу.

У меня на Windows XP x64 такая тулза есть:

Не совсем понял причем здесь win 2k? Важен тип раздела NTFS.
Я понял проблему с симлинками!
И вижу только 2 проблемы с хардлинками:
1) Создавать можно только в пределах раздела
2) Создавать можно только на разделах определенного типа
Ты это имеешь ввиду?

Для винды нашел в MSDN:

Под Linux вроде должно быть что-то типа функции "link"?

да.

http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx
http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=link&category=2

тип раздела тоже важен, но нативная поддержка куда важнее.

почти такие же ограничения и на симлинки. но это ограничения системы, а я говорил про проблемы реализации в Qt

lit-uriy, основной вопрос исчерпан в предыдущем посте. предлагаю оставить пока что как есть...

Из MSDN

угу, для хардлинков (их указывал как "и" - получилось как будто и хардлинки только начиная с висты).
а отвечал на

вот и реализовал поддержку хардлинков, симлинков и алиасов (ну, почти реализовал)...
шурша манами, не встретил упоминаний того, можно ли из хардлинки (POSIX | NTFS) прочитать путь к источнику...как будто бы нет...
но решил обратиться к тем, кто знает наверняка, ибо закралось подозрение, что путь вытащить всё же можно (как минимум у junction'ов можно вытащить REPARSE_DATA и расковырять путь к источнику...)

По моему, для ядра хардлинки на один и тот-же источник данных (inode) ничем не отличаются.

верно. но мне не для внутреннего поведения нужно, а юзверю показать что-то на QFileInfo::symLinkTarget()

Пустую строку.  ???

пустая строка возвращается, если запись - не линк и иногда если таргет линка не существует.
вот я и думаю как мне рулить хардлинки - считать их вообще линками или пусть остаются обычными файлами?

После создания они и становятся обычными файлами, друг от друга ничем не отличающимися.
Поэтому, пустая строка, с точки зрения документации, будет в самый раз.  :)
IMHO.

Еще мысли вслух.
Можно проверять количество линков и если их больше 1, считать файл hardlink'ом и выводить в QFileInfo::symLinkTarget() абсолютный путь к файлу.

Лучше не надо! Поскольку никакого отношения к symLink не имеет.
Однозначно, всегда выводить пустую строку.

а по мне дак "или пусть остаются обычными файлами?"

Так они и есть обычные файлы, вернее один файл!
Можно сказать так: Имя файла это Hard Link на "физический источник" inode
"Физический файл" просто может иметь несколько имен, т.е хардлинков и они все равнозначны!

нет, сорц не может быть таргетом.

> thiago: a hardlink has no target
значит, остаются симлинки и алиасы. есть ещё junction'ы, но пока не знаю куда их присобачить. возможно, для < висты будут играть роль кастрированных симлинков (только папки на папки, если правильно помню)...

поправка - они неравнозначны. мелкомягкие, как всегда, вые?нулись/сэкономили - в итоге инфа для хардлинков обновляется только при открытии и на получение инфы по хэндлу (ctrl+r в тотале наглядно показывает как работает это убожество).

даже захотелось поставить свисту - чтобы иметь нормальные симлинки...но я знаю, что мне всё-равно будет лень переустанавливать систему :)
лучше я чуть позже попрошу кого-нибудь из счастливых обладателей потестить изменения...

В FAR та же фигня, видимо работают через _stati64. Проверил(_stati64), действительно криво выдает для второго файла после изменения размера певого и наоборот.
Проверил что ситуация симметрична - не важно какой файл был исходным. Важно что ты изменяешь один, а у другого информация не обновляется. Так что они равнозначны!
А ктати QFile::size() - выдает правильно, при этом файл не открывает, т.е через тот же _stati64 после QFile::size() получаем все ту же ерунду!
И QFile::bytesAvailable() работает корректно - писал в один, а читал из другого!!!

хехе...научился работать с junction'ами - будут использоваться в качестве фоллбэка для симлинков, если версия < висты :)

у кого стоит виста и кто может+хочет помочь?
в аттаче простенький тестовый код - буду признателен, если кто-нибудь его соберёт и погоняет, а консольные сообщения выложит здесь...

и было бы совсем чудесно увидеть дамп REPARSE_DATA_BUFFER (http://msdn.microsoft.com/en-us/library/ms791514.aspx), полученный в isSymlink(..) для нативной симлинки (указатель rdb)

благодарю всех откликнувшихся...мой предыдущий пост уже можно считать неактуальным...
вчера умельцы рубили свет - на одной из машин...эммм...хрюкнула хрюша :) - решили поставить свисту...
/* зы: не доверяйте активаторам, которые подменяют *.sys - в сп2 эта дыра уже закрыта :) */

offtop: а я хотел помочь, тока не совсем в теме про все эти *линки, да и скачал файлик, начал компилить, он ругнулся на отсутствие апишной ф-и, я расстроился и бросил это дело :D