Hosszú, 250 utf8 karaktert tartalmazó állomány nevekhez fájlrendszert

Linux alatt keresek a problémára megoldást, ha lehetséges el kell kerülni a file átnevezés, eredeti név nyilvántartása megoldást.

Hozzászólások

Mármint POSIX? Az nehéz ügy lesz.
Reiser4 karbantartott még?

Reiser4
Még élőnek látszik: https://reiser4.wiki.kernel.org/index.php/Main_Page
2019-04-12 - Reiser4 for Linux-5.0

Bár én is inkább fájlnévből képezett sha256/512/bármi és SQL/txt_fájl/bármi transzformáció párosát tartom stabilabbnak. Ütközésre még egy karaktert fenntartva a végén.

NTFS, exFAT vagy akár FAT16/FAT32 is, ha UCS-2 elég :)
De azért nézz rá, hogy Linux VFS nem korlátoz-e. Ott mintha byte-ban lenne a max limit 255..

Az ilyen hosszú fájlnevek Windowson is szívás. Egyik program megnyitja, másik nem. Az lyen fájlok mozgatásánál figyelmeztet a Windows, ha másolod/mozgatod, hogy probléma lehet belőle.
Egyszer melóban futottam már bele olyanba is, hogy a kollegina átnevezte a pdf doksikat, jó hosszú nevűekre, aztán szólt, hogy miért nem nyitja meg az Acrobat Reader, meg miért nem lehet csatolni e-mail-hez.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Nem lehetne hashelni a fájlneveket, egy egyszerűbb db-ben meg nyilvántartani, mi-mihez tartozik? Könyvtárak bontás se játszik? Tudom, pathnál is vannak határok, csak nem tudom, milyenek

Ha 255 char fölé akarsz menni Linuxon az szívás lesz. A /usr/include/linux/limits.h-ban van definiálva a NAME_MAX, minden normálisan megírt program ezt használja fájlnév limit gyanánt, kb. az összes alapprogramot újra kéne fordítanod, ha e fölé mész.

Mi az alapproblema, amit meg akarsz oldani vele?

így már reiser4 fájlrendszerrel is csak 1325 lehet.

troll:
echo farkas >"Így hívják azt az állatot, amelyik Piroskával (красная шапочка) beszélgetett az erdőben, és csak azután merte megenni fondorlatos csellel, miután már a nagymamát is megette.txt"

/troll
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

fellegis@DSK01:/tmp/proba$ echo farkas >"Így hívják azt az állatot, amelyik Piroskával (красная шапочка) beszélgetett az erdőben, és csak azután merte megenni fondorlatos csellel, miután már a nagymamát is megette.txt"
fellegis@DSK01:/tmp/proba$ ls
'Így hívják azt az állatot, amelyik Piroskával (красная шапочка) beszélgetett az erdőben, és csak azután merte megenni fondorlatos csellel, miután már a nagymamát is megette.txt'
fellegis@DSK01:/tmp/proba$ cat "Így hívják azt az állatot, amelyik Piroskával (красная шапочка) beszélgetett az erdőben, és csak azután merte megenni fondorlatos csellel, miután már a nagymamát is megette.txt"
farkas

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Egyébként a nemzetközi környezetben miért akarnak a felhasználók mondjuk 80-100 karakteres vagy még hosszabb fájlneveket használni?

Az még gombócból is sok :-)

De most komolyan. Általában az általam megismert felhasználók nem szokták a fájlrendszer határait feszegetni a hosszú fájlnevekkel*.
Hosszú fájlnevet beírni is és végigolvasni is macera.

*Bezzeg könyvtár a könyvtárban sok szinten keresztül, és hipp-hopp bele szoktak futni abba, hogy a teljes path túl hosszú.

Mindent meg lehet oldani csak amint elmondod az ügyfélnek mennyibe fog kerülni rögvest szükség se lesz rá.

Saját magadnak kell fordítgatnod mindent és tesztelned, mindezt pedig karbantartani (ugye jönnek a frissítések). Esetleg ha teljesen saját szoftvert írsz és nem használsz szinte semmi userland toolt, akkor elég a limitet módosítani vagy akár a VFS-t kihagyni. De akkor megint jön a kérdés, hogy minek szívasd magad a fájlrendszerrel és ki fogja ezt fizetni.

Legújabb Windows-on NTFS-el egyébként sokkal egyszerűbben lehetne boldogulni, mivel ott van rá támogatás. De ha ott is nem saját alkalmazás írsz, akkor bőven belefuthatsz valami régi limitbe.

Csak azért kérdezem, mert:
1) lehet, hogy nincs is probléma. Lehet, hogy a felhasználók valójában nem is adnak ilyen hosszú neveket, csak valaki óvatosságból leírta, hogy ez a követelmény, mert hátha egyszer majd valaki ezt akarja. (Persze nem tudom, nálad konkrétan mi a helyzet, de láttam már BA-t, aki mert nagyot álmodni).
2) előfordul az, hogy az, aki a követelményt adja, nem érti a hatását. Láttam már arra is példát, hogy jött valaki, elmondta, hogy mit akar, a fejlesztőcsapat osztott-szorzott és kihozták, hogy x hónap alatt, n pénzért lehetne megvalósítani. Ettől (főleg az x-től) a szívükhöz kaptak, mert hogy jön a határidő, meg miegymás. Ezután a fejlesztők javasoltak pár változtatást és egyszerűsítést, és így valami létező komponenst fel tudnának használni, és hirtelen x hónap helyett 1-2 hét alatt kész a cucc, és persze lényegesen olcsóbban. Szóval néha nem árt elbeszélgetni az álmodozókkal.
3)ha jelenleg is ilyen hosszúnevű fájlokat használnak, akkor miért kell lecserélni a jól bevált mostani megoldást?

sőt, egy másik probléma is felvetődik: egy parancssor hossza elvileg 32kbyte... ha ilyen hosszúnevű mappákban hosszúnevű mappákban hosszúnevű fájlok vannak, előbb-utóbb ez a határ is túllépődhet.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

ha valami program generalja ezeket a hosszu fajlneveket, akkor csinalhatsz preloadert, ami konvertalja a fajlneveket ugy hogy
szetbontod a fajlneveket 250-es reszekre, es a tobbi konyvtarneven tarolod. pl nagyononhosszufajlnev.txt -> nagyonon/hosszu/fajlnev.txt

persze ha openoffice meg gimppel akartok ilyen hosszu fajlneveket hasznalni akkor ugyis a path limitbe futtok bele.

vagy https://unix.stackexchange.com/questions/283149/fuse-overlay-filesystem…

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!