ڈیٹا ٹرانسفر - lolly-backup بنڈل

ایک Lolly صارف جو کچھ بھی جمع کرتا ہے وہ اس کے اپنے ڈیوائس پر رہتا ہے - کوئی اکاؤنٹ نہیں، کوئی کلاؤڈ نہیں۔ ڈیٹا-ٹرانسفر بنڈل وہ طریقہ ہے جس سے یہ قدر منتقل ہوتی ہے: اسے ایک انسٹال پر ایکسپورٹ کریں، فائل کو کسی بھی ذریعے (USB، AirDrop، خود کو ای میل، نیٹ ورک شیئر) سے لے جائیں اور اسے دوسرے پر امپورٹ کریں۔ فائل ہی ٹرانسپورٹ ہے۔ ٹارگٹ آف لائن یا آن لائن ہو سکتا ہے۔ کوئی فرق نہیں پڑتا، کیونکہ کبھی کوئی سرور سے بات نہیں ہوتی۔

signed by Lolly2026-10-21vector SVG9 paths~4.9k nodes11 groups56 KBخود جانچیںدستخط شدہ فائل حاصل کریں signed by Lolly2026-10-21vector SVG9 paths~4.9k nodes11 groups56 KBخود جانچیںدستخط شدہ فائل حاصل کریں

یہ صفحہ فارمیٹ اسپیک ہے۔ اینڈ-یوزر واک تھرو کے لیے دیکھیں اپنا کام تلاش اور بازیافت کریں → اپنا کام دوسری ڈیوائس پر منتقل کریں۔ عملدرآمد shells/web/src/data-transfer.ts میں ہے، اور tests/data-transfer.test.ts راؤنڈ-ٹرپ کنٹریکٹ کو پن کرتا ہے۔

دائرہ کار۔ ایک بنڈل صارف کا ڈیٹا لے کر جاتا ہے، کیٹلاگ ٹولز نہیں۔ کیٹلاگ ٹولز اور کیٹلاگ اثاثے علیحدہ طور پر سنک ہوتے ہیں اور فرض کیا جاتا ہے کہ وہ ٹارگٹ پر پہلے سے موجود ہیں (بدترین صورت میں زیادہ ورژن پر)؛ جو ٹولز صارف نے خود بنائے ہوں وہ profile.json کے اندر سفر کرتے ہیں۔ امپورٹ کبھی کسی کیٹلاگ ٹول کو انسٹال یا اپ گریڈ نہیں کرتا۔

اہداف

• ایک فارمیٹ، ہر شیل۔ وہی بائٹس ویب PWA، Tauri ڈیسک ٹاپ/موبائل ایپس اور کسی بھی مستقبل کے شیل کے ذریعے تیار اور استعمال کیے جاتے ہیں۔ بنڈل ہی کنٹریکٹ ہے۔ ہر شیل کا کیپیبلٹی برج اس کے پیچھے فی-پلیٹ فارم اڈاپٹر ہے۔
• سفر میں محفوظ رہتا ہے۔ ٹرانزٹ میں خراب یا ٹرنکیٹ ہونے والا بنڈل امپورٹ پر واضح طور پر ناکام ہوتا ہے، کبھی آدھا بحال نہیں ہوتا۔
• اس ورژن سے آگے تک چلتا ہے۔ ایک پرانی ایپ اب بھی نئے بنڈل کے پہچانے جانے والے حصے امپورٹ کر سکتی ہے۔ حقیقی معنوں میں breaking فارمیٹ کو صاف طور پر مسترد کر دیا جاتا ہے۔
• مرج کے لیے محفوظ۔ پہلے سے استعمال میں موجود انسٹال پر امپورٹ کرنا کبھی اس چیز کو نہیں مٹاتا جو بنڈل میں نہیں تھی۔

لفافہ

ایک بنڈل ایک سادہ .zip ہے۔ ڈاؤن لوڈ کا نام اس شخص کے مطابق رکھا جاتا ہے جس سے یہ تعلق رکھتا ہے - LollyTools-<First>-<Last>-<YYYY-MM-DD>-<n>.zip (مثال کے طور پر LollyTools-Ada-Lovelace-2026-06-26-1.zip) - تاکہ بیک اپس سے بھرا Downloads فولڈر قابلِ فہم رہے۔ پہلا اور آخری حصہ پروفائل سے آتا ہے اور جب سیٹ نہ ہو تو چھوڑ دیا جاتا ہے۔ کوئی پروفائل نہ ہونے پر LollyTools-2026-06-26-1.zip ملتا ہے، اور صرف پہلا نام ہونے پر LollyTools-Ada-2026-06-26-1.zip ملتا ہے۔ ہر حصے کو فائل نام کے لیے محفوظ ٹوکن میں صاف کیا جاتا ہے (یونیکوڈ حروف/ہندسے برقرار، اسپیس/رموزاوقاف ہٹا دیے جاتے ہیں، زیادہ سے زیادہ 32 حروف)۔ <n> ایک فی-دن، فی-ڈیوائس ترتیب ہے، لہٰذا اسی دن دہرائے گئے ایکسپورٹس آپس میں نہیں ٹکراتے اور ترتیب میں رہتے ہیں۔ shells/web/src/data-transfer.ts میں backupFilename() نام بناتا ہے۔ زپ کا مواد نام سے قطع نظر ایک جیسا رہتا ہے۔ اندر:

بنڈل جان بوجھ کر ایک سادہ زپ ہے: یہ کسی بھی ٹرانسپورٹ میں مکمل حالت میں بچ جاتا ہے، اور کوئی بھی ان زپ ٹول اس کا معائنہ کر سکتا ہے۔

profile.json سب سے چھوٹا حصہ ہے اور وہ ہے جسے ریڈر ایپ میں سب سے پہلے دیکھتا ہے: وہ تفصیلات جو تخلیق کار ایک بار پُر کرتا ہے، ساتھ ہی وہ آپٹ-ان جو ٹولز کو انہیں استعمال کرنے دیتا ہے۔

signed by Lolly2026-10-21vector SVG15 paths~1.2k nodes30 groups1 image40 KBخود جانچیںدستخط شدہ فائل حاصل کریں

manifest.json

{
  "format": "lolly-backup",
  "formatVersion": 3,
  "minReader": 1,
  "app": "lolly",
  "exportedAt": "2026-06-22T09:30:00.000Z",
  "counts": { "profile": true, "sessions": 2, "userAssets": 4, "prefs": 3, "assetVersions": 1, "fileOperations": 1 },
  "integrity": {
    "profile.json": "sha256-…",
    "sessions.json": "sha256-…",
    "assets.json": "sha256-…",
    "assets/blobs/0.bin": "sha256-…",
    "file-history.json": "sha256-…",
    "file-history/versions/0.bin": "sha256-…",
    "file-history/results/0.bin": "sha256-…",
    "prefs.json": "sha256-…"
  }
}

ورژن پالیسی (فارورڈ کمپیٹیبلٹی)

formatVersion اور minReader کے درمیان تقسیم ہی وہ چیز ہے جو فارمیٹ کو پرانی انسٹالیشنز کو بے یار و مددگار چھوڑے بغیر بڑھنے دیتی ہے:

• ایک ریڈر بنڈل امپورٹ کرتا ہے جب manifest.minReader ≤ اپنے ہی ریڈر ورژن کے برابر یا کم ہو۔ یہ صرف اسی صورت میں انکار کرتا ہے ("needs a newer version of the app" کے ساتھ) جب بنڈل واضح طور پر نئے ریڈر کا تقاضا کرے۔
• ایک اضافی (additive) تبدیلی - ایک نیا اختیاری حصہ، یا ایک نیا اختیاری مینی فیسٹ فیلڈ - formatVersion کو بڑھاتی ہے مگر minReader کو تبدیل نہیں چھوڑتی۔ پرانی ایپس اب بھی ہر وہ حصہ امپورٹ کرتی ہیں جسے وہ پہچانتی ہیں۔ جن حصوں کو وہ نہیں پہچانتیں انہیں چھوڑ دیا جاتا ہے (نیچے دیکھیں)، خاموشی سے ضائع نہیں کیا جاتا۔
• ایک breaking تبدیلی - جہاں کسی حصے کا غلط امپورٹ ڈیٹا کو خراب کر دے، یا جہاں پہلے سے اختیاری حصہ لازمی بن جائے - minReader کو بڑھاتی ہے۔ پرانی ایپس پھر کچھ ایسا امپورٹ کرنے کے بجائے جسے وہ سنبھال نہیں سکتیں، صاف طور پر انکار کر دیتی ہیں۔
• اگر کوئی مستقبل کا بنڈل formatVersion سیٹ کرے مگر minReader چھوڑ دے، تو ریڈرز احتیاطاً formatVersion پر گیٹ کرنے پر واپس چلے جاتے ہیں (تبدیلی کو breaking سمجھتے ہوئے)۔

مصنفین کے لیے عمومی اصول: اگر ہر موجودہ ریڈر آپ کے اضافے کو نظر انداز کر کے بھی درست کام کرے، تو یہ additive ہے - formatVersion بڑھائیں، minReader چھوڑ دیں۔ ورنہ minReader بڑھائیں۔

انٹیگریٹی

جب manifest.integrity موجود ہو، ایک ریڈر ہر درج شدہ حصے کا SHA-256 کچھ بھی لکھنے سے پہلے تصدیق کرتا ہے۔ کوئی عدم مطابقت ("failed its integrity check") یا غائب حصہ ("incomplete") پوری امپورٹ کو روک دیتا ہے - کوئی جزوی بحالی نہیں ہوتی۔ یہ اس خرابی کو پکڑتا ہے جو فائل ٹرانسپورٹ لا سکتا ہے (ایک ٹرنکیٹڈ AirDrop، ایک ای میل گیٹ وے جس نے اٹیچمنٹ کو دوبارہ انکوڈ کیا، ایک خراب USB سیکٹر)۔

انٹیگریٹی جان بوجھ کر best-effort ہے: یہ صرف وہاں لکھی جاتی ہے جہاں Web Crypto دستیاب ہو (ہر محفوظ براؤزر کانٹیکسٹ اور جدید Node)، اور صرف اسی صورت میں تصدیق کی جاتی ہے جب میپ اور Web Crypto دونوں موجود ہوں۔ میپ کے بغیر بنڈل - مثال کے طور پر انٹیگریٹی کے وجود میں آنے سے پہلے کا کوئی بنڈل - بلا تبدیلی امپورٹ ہوتا ہے۔ "Cannot verify" کو کبھی "corrupt" نہیں سمجھا جاتا۔

مینی فیسٹ نہ خود اپنی فہرست بناتا ہے اور نہ دوبارہ تیار کردہ lolly.txt README کی۔ ڈائجسٹس صرف انہی حصوں کا احاطہ کرتے ہیں جن کا مینی فیسٹ ضامن ہے۔

امپورٹ کی سیمنٹکس

امپورٹ ایک merge ہے، کبھی replace-all نہیں:

• ٹارگٹ پر موجودہ ڈیٹا اپنی جگہ چھوڑ دیا جاتا ہے۔
• جب کوئی سیشن سلاٹ یا اپ لوڈ شدہ تصویر کا id دونوں پر موجود ہو، تو حال ہی میں محفوظ کی گئی کاپی رکھی جاتی ہے، تاکہ کوئی پرانا بیک اپ ٹارگٹ پر نئے کام کو کبھی اوور رائٹ نہ کرے۔ برابر یا نامعلوم اوقات ہونے پر ٹارگٹ کی کاپی رکھی جاتی ہے۔ creation history والی ویب تنصیب پر، یہی اصول طے کرتا ہے کہ کسی creation کی کون سی کاپی موجودہ رہتی ہے، اور دوسری کاپی ایک protected draft کے طور پر رکھی جاتی ہے (نیچے دیکھیں)۔
• پروفائل ریکارڈ ضم کیا جاتا ہے، تبدیل نہیں کیا جاتا۔ ٹارگٹ پر موجود ہر فولڈر اپنے مواد کے ساتھ برقرار رہتا ہے؛ بنڈل کا کوئی فولڈر جو ٹارگٹ کے پاس نہیں وہ شامل کر دیا جاتا ہے، اور جو فولڈر دونوں پر ہو وہ ٹارگٹ کا نام اور parent برقرار رکھتا ہے اور بنڈل کے وہ اراکین پا لیتا ہے جو اس کے پاس نہیں تھے۔ ٹارگٹ پر کسی فولڈر میں فائل شدہ سیشن وہیں فائل رہتا ہے۔
• پسندیدہ (ٹولز، کیٹلاگ اثاثے اور Projects آئٹمز) یکجا کر دیے جاتے ہیں۔ بنڈل کے ٹیمپلیٹس، Projects ٹیمپلیٹس اور یوزر ٹولز تبھی شامل کیے جاتے ہیں جب ٹارگٹ کے پاس اُس id والا کوئی ریکارڈ نہ ہو۔ دونوں کے Trash اندراجات رکھے جاتے ہیں، تاکہ جو آئٹم کسی بھی تنصیب پر بحال کیا جا سکتا تھا، اب بھی کیا جا سکے۔
• پروفائل کا ہر دوسرا فیلڈ (نام، رابطہ تفصیلات، زبان، فیچر فلیگز، پوشیدہ ٹولز اور باقی سیٹنگز) ٹارگٹ کی قدر برقرار رکھتا ہے۔ جو فیلڈ ٹارگٹ پر خالی ہو وہ بنڈل کی قدر لے لیتا ہے۔ prefs.json کے لیے بھی یہی ہے: کوئی ترجیح صرف وہیں لکھی جاتی ہے جہاں ٹارگٹ کے پاس کوئی نہیں۔
• Device sync کا معمول کا اطلاق اس کا استثنا ہے: ڈیوائسز کو ہم قدم رکھتے ہوئے، یہ synced کاپی کا پروفائل ریکارڈ، ترجیحات، سیشنز اور تصاویر لے لیتا ہے۔ کسی پرانی کاپی کو بحال کرنا بھی یہی کرتا ہے، کیونکہ یہ جان بوجھ کر وقت میں پیچھے جاتا ہے۔ پہلا جوائن، اسے اس ڈیوائس پر لائیں، ایک امپورٹ کی طرح ضم کرتا ہے۔
• پرانے اثاثہ ورژنز اور آپریشن IDs ناقابلِ تبدیل استثنائیات ہیں: دہرایا گیا امپورٹ idempotent ہوتا ہے، اور جو ID پہلے سے مختلف بائٹس/ہسٹری کا نام رکھتی ہو اسے مسترد کیا جاتا ہے، اوور رائٹ نہیں کیا جاتا۔ کسی ایک جیسے موجودہ اثاثے کو دوبارہ امپورٹ کرنا اس کا ورژن برقرار رکھتا ہے۔ کسی بدلے ہوئے موجودہ اثاثے کو ایک مختلف ورژن رکھنا ضروری ہے۔
• Creation history بھی ضم ہوتی ہے۔ جو creation دونوں طرف ہو، وہ حال ہی میں محفوظ کی گئی کاپی کو موجودہ کے طور پر اور دوسری کاپی کو ایک protected draft کے طور پر رکھتی ہے؛ جو creation اُس سلاٹ کا استعمال کرتی ہے جسے ٹارگٹ کسی دوسری creation کے لیے استعمال کرتا ہے، وہ اس کے ساتھ شامل کر دی جاتی ہے؛ ٹارگٹ کے Trash میں موجود creation وہیں رہتی ہے۔ کوئی checkpoint id جو ٹارگٹ پر مختلف مواد کا نام رکھتی ہو، وہ ٹارگٹ کی کاپی برقرار رکھتی ہے۔ جو آرکائیو اپنے ہی چیکس میں ناکام ہو جائے، وہ کسی بھی پروفائل، سیشن، اثاثہ یا ترجیح کی تبدیلی سے پہلے ہی امپورٹ روک دیتا ہے۔ ایک جیسا دہرایا گیا امپورٹ کوئی اسٹوریج شامل نہیں کرتا۔
• جو چیز بنڈل میں نہیں تھی اسے چھوا تک نہیں جاتا۔ وہ سیشن جو ٹارگٹ کے پاس تھا مگر بنڈل کے پاس نہیں تھا، امپورٹ کے بعد بھی موجود رہتا ہے۔

محفوظ شدہ سیشنز خودکار طور پر اپنی تصاویر سے دوبارہ منسلک ہو جاتے ہیں: اثاثے کے حوالے id کے ذریعے رکھے جاتے ہیں، اور اپ لوڈ شدہ تصاویر بحال ہونے کے بعد برج انہیں دوبارہ حل کرتا ہے (اسے بہرحال ایسا کرنا ہی ہے، کیونکہ blob: URLs ری لوڈ کے بعد باقی نہیں رہتے)۔

امپورٹ کا خلاصہ { profile, sessions, userAssets, prefs, skipped, failedAssets } رپورٹ کرتا ہے۔ failedAssets ان اپ لوڈ شدہ اثاثوں کو شمار کرتا ہے جنہیں بحال نہیں کیا جا سکا (مثلاً ڈیوائس اسٹوریج بھرا ہونا)۔ یہ skipped سے مختلف ہے، جو ایک فارورڈ-کمپیٹیبل نئے رائٹر کے ان حصوں کو شمار کرتا ہے جنہیں یہ بلڈ نہیں پہچان سکا۔ UI skipped ظاہر کرتا ہے ("… · N newer items skipped")، تاکہ بحالی اس بارے میں دیانتدار رہے کہ اس نے کیا پیچھے چھوڑا۔

جب فائل ہسٹری موجود ہو، تو خلاصہ assetVersions، fileOperations اور failedHistory بھی ساتھ رکھتا ہے۔ اسٹوریج ختم ہو جانا یا ناقابلِ تبدیل-ID تصادم جزوی بحالی کا سبب بن سکتے ہیں؛ UI صارف کو سورس بیک اپ برقرار رکھنے کو کہتا ہے۔ کلاؤڈ Sync جزوی یا غیر معاون بحالی کے بعد اپنا لاگو شدہ ریویژن آگے نہیں بڑھاتا، تاکہ اسنیپ شاٹ دوبارہ کوشش کے لیے دستیاب رہے۔ بحالی تمام پروفائل/سیشن/اثاثہ/ہسٹری اسٹورز میں ایک ہی transaction نہیں ہے۔

Creation history (v3)

History کی صلاحیت رکھنے والے ویب ہوسٹ سے دستی بیک اپس میں revision-history.json شامل ہوتا ہے، جس کا اپنا { version: 1, documents, revisions, recoveries } اسکیما ہے۔ یہ محفوظ رکھی گئی IDs، canonical ان پٹ اسنیپ شاٹس، ورژن اسٹیمپس، raster پیش نظارے اور علیحدہ writer ڈرافٹس رکھتا ہے۔ ہسٹری اڈاپٹر موجودہ سیشنز اور ان کے heads کو ایک ہی ریڈ transaction میں کیپچر کرتا ہے؛ sessions.json پرانے readers کے لیے وہی موجودہ اسنیپ شاٹس استعمال کرتا ہے۔

بحالی آرکائیو کو ایک transaction میں کمٹ کرنے سے پہلے payload کا SHA-256 اور byte شمار، منفرد شناختیں، document/head تعلقات، نسب، ٹائم اسٹیمپس، پیش نظارے کی اقسام اور حدود چیک کرتی ہے۔ compacted parent references غیر موجود ہو سکتے ہیں۔ موجودہ ورکنگ کام کبھی خاموشی سے تبدیل نہیں کیا جاتا: جب کوئی creation دونوں طرف ہو، تو جو طرف موجودہ کے طور پر نہیں رکھی جاتی وہ ایک protected draft بن جاتی ہے۔ آرکائیو کی 384 MiB ٹرانسفر حد کو واضح طور پر چیک کیا جاتا ہے، اور اسٹوریج کی حدیں محفوظ رکھے گئے checkpoints کو کاٹے بغیر نافذ کی جاتی ہیں۔ مجموعی بیک اپ اب بھی ان-میموری ZIP implementation استعمال کرتا ہے اور یہ کوئی streaming آرکائیو نہیں ہے۔

خلاصہ میں revisions اور recoveryDrafts شامل ہوتے ہیں، جو صرف یہ گنتے ہیں کہ اس امپورٹ نے کیا شامل کیا، اور added، kept، replaced، copies اور hidden یہ بتانے کے لیے کہ ہر creation کیسے ضم ہوئی۔ اس صلاحیت کے بغیر کوئی شیل عام سیشنز بحال کرتا ہے اور ہسٹری حصے کو چھوڑا گیا رپورٹ کرتا ہے۔ Native فائل سسٹم ہسٹری غیر معاون رہتی ہے جب تک اس کا اڈاپٹر durable ہسٹری transactions فراہم نہ کرے۔ P2P guest state کے پاس کوئی durable ہسٹری یا ریکوری آرکائیو نہیں ہے۔

ذاتی اسنیپ شاٹ Sync جان بوجھ کر creation history کو خارج رکھتا ہے۔ کسی ایسے مقامی دستاویز پر اسنیپ شاٹ لگانا جس کی ہسٹری ہو، اس کی سابقہ ورکنگ حالت کو ایک علیحدہ ریکوری ڈرافٹ کے طور پر محفوظ کرتا ہے اور کسی بھی کھلے ایڈیٹر کا write token غیر معتبر کر دیتا ہے۔ اس کے ناقابلِ تبدیل checkpoints ڈیوائس پر رہتے ہیں۔ یہ اسنیپ شاٹ کی تبدیلی کے دوران مقامی ہسٹری کی حفاظت کرتا ہے؛ یہ ایک ساتھ چلنے والی ڈیوائسز کی ہسٹریز کو مرج نہیں کرتا۔

پرانے اثاثہ حوالے برقرار رکھے جاتے ہیں، جبکہ رینڈرنگ اب بھی destination کی موجودہ لائبریری کے ذریعے اثاثے حل کرتی ہے۔ یہ آرکائیو ابھی تک پرانے اثاثہ بائٹس یا پرانے ٹول رینڈرز کی ضمانت نہیں دیتا۔ اثاثہ-ورژن اور فائل-نتیجہ بائٹس اپنے موجودہ علیحدہ بیک اپ حصے کے ذریعے سفر کرتے رہتے ہیں۔

محفوظ شدہ ورژنز اور فائل نتائج (v2)

اختیاری ہسٹری حصہ { version: 2, assetVersions: [...], operations: [...], batches: [...] } رکھتا ہے؛ readers پرانی history-v1 شکل بھی بغیر batches کے قبول کرتے ہیں۔ ہر اسنیپ شاٹ مستحکم اثاثہ ID اور اصل ورژن، اس کا save وقت، byte لمبائی اور hex SHA-256 شناخت کرتی ہے، نیز ایک اثاثہ ریکارڈ جس کے _file اور اختیاری _credentialFile بائنری حصوں کی طرف اشارہ کرتے ہیں۔ Operations اصل فائل کے حقائق، request، report، ٹائم اسٹیمپس اور اختیاری نتیجہ _file رکھتے ہیں؛ اسٹوریج بیک اینڈ کے نام، OPFS handles اور execution leases سفر نہیں کرتے۔ پرانے صرف-history-v1 readers امپورٹ سے پہلے نئے ہسٹری ورژن کو مسترد کر دیتے ہیں، بجائے اس کے کہ batch membership خاموشی سے گرا دیں۔

Batch مینی فیسٹس پراسیسنگ سے پہلے ہر منتخب سورس ریکارڈ کرتے ہیں، بشمول وہ فائلیں جو کبھی پڑھی ہی نہیں گئیں، منسوخ اراکین، نتیجے کی جگہ محفوظ کرنے میں ناکامی اور روکا گیا کام۔ ہر رکن کی ایک مستحکم operation ID، سورس reference/facts، درخواست کردہ output نام اور terminal report ہوتی ہے۔ ایک نہ پڑھے گئے سورس کے پاس اعلان شدہ facts ہوتے ہیں، کوئی گھڑا ہوا digest نہیں۔ امپورٹ رکن کی شناخت اور کسی بھی ساتھ لائی گئی operation report سے مطابقت کی تصدیق کرتا ہے۔ Batch reports تب بھی دستیاب رہتی ہیں جب انفرادی نتائج واضح طور پر ہٹا دیے گئے ہوں، مگر ایک رسید یہ ظاہر نہیں کرتی کہ اس کے output بائٹس اب بھی محفوظ ہیں۔

• ہر معلوم ہسٹری ریکارڈ، رپورٹ اور حوالہ شدہ فائل کی توثیق کسی بھی پروفائل یا اثاثہ امپورٹ رائٹ سے پہلے کی جاتی ہے۔ غائب بائٹس اور نامطابق SHA-256 ناکام ہو جاتے ہیں چاہے envelope کے پاس کوئی integrity map نہ ہو۔ نکالے گئے credentials byte arrays ہی رہتے ہیں، بشمول پرانے writers سے امپورٹس جنہوں نے انہیں numeric-key objects کے طور پر JSON-serialize کیا تھا۔
• جاری آپریشنز بیک اپ میں ایک وضاحتی failure report اور کوئی نتیجہ نہ رکھنے والے interrupted ریکارڈز بن جاتے ہیں۔ بحالی کبھی بھی بیک گراؤنڈ کام دوبارہ شروع نہیں کرتی اور نہ کوئی فعال lease امپورٹ کرتی ہے۔ دوبارہ کوشش کے لیے اصل فائل منتخب کرنا ضروری ہے، جسے دستیاب ہونے پر اس کے ریکارڈ شدہ SHA-256 کے خلاف چیک کیا جاتا ہے۔
• بحال شدہ نتائج اپنے بائٹس اور میٹا ڈیٹا کو IndexedDB میں ایک ساتھ کمٹ کرتے ہیں۔ عام نئے نتائج دستیاب ہونے پر OPFS استعمال کرتے ہیں، ساتھ IndexedDB fallback کے۔ کسی موجودہ live آپریشن کو کبھی امپورٹ سے تبدیل نہیں کیا جاتا۔
• ہسٹری ZIP اسمبلی اب بھی میموری میں ہے: موجودہ حد 256 MiB ہسٹری payload کی، 4 MiB ہسٹری میٹا ڈیٹا کی، زیادہ سے زیادہ 100 operations، 100 batches اور 2,000 snapshots ہے۔ ایکسپورٹ زیادہ سائز یا نامکمل ہسٹری کو واضح طور پر مسترد کرتا ہے؛ یہ اسے کبھی خاموشی سے نہیں چھوڑتا۔ پرانی مقامی کاپیاں ہٹانے سے پہلے اہم ورژنز/نتائج انفرادی طور پر ڈاؤن لوڈ کریں۔ یہ حدیں فونز کے لیے ماپی گئی peak-memory ضمانت نہیں ہیں۔
• مقامی نتیجہ ہسٹری کا بجٹ 512 MiB اور 100-ریکارڈ کیپ ہے۔ اثاثہ اسنیپ شاٹس کا الگ 512 MiB بجٹ اور فی اثاثہ زیادہ سے زیادہ 20 پرانے ورژنز ہیں؛ نکالے گئے credential بائٹس اسی snapshot بجٹ میں شمار ہوتے ہیں۔ بحالی ان حدود کا خیال رکھتی ہے اور کبھی خاموشی سے موجودہ یوزر ڈیٹا نہیں ہٹاتی۔
• مقامی batch میٹا ڈیٹا کا الگ 4 MiB بجٹ ہے، زیادہ سے زیادہ 100 مینی فیسٹس اور فی batch 20 اراکین۔ زیرِ التوا اراکین میٹا ڈیٹا صلاحیت مخصوص رکھتے ہیں، فی رکن 32 KiB رپورٹ کی حد کے ساتھ۔ یہ ایک منطقی بجٹ ہے، براؤزر ڈسک اسپیس کی ضمانت نہیں؛ ایک حقیقی quota ناکامی سامنے لائی جاتی ہے اور ان-میموری رپورٹ ڈاؤن لوڈ کے قابل رہتی ہے۔ کسی batch رکن کو دوبارہ آزمانا پرانی رپورٹ پر لکھے بغیر ایک نیا batch بناتا ہے۔ کسی batch ریکارڈ کو ہٹانا انفرادی نتیجہ بائٹس یا لائبریری اثاثے نہیں ہٹاتا۔
• تبدیل شدہ نتائج کو واضح طور پر لائبریری میں شامل کیا جا سکتا ہے، بغیر normalization یا re-encoding کے۔ Source/output ہیشز اور operation کا تعلق اثاثے کے ساتھ چلتے ہیں۔ دہرائے گئے اضافے ایک غیر تبدیل شدہ کاپی دوبارہ استعمال کرتے ہیں؛ کسی ترمیم شدہ کاپی کو کبھی اوور رائٹ نہیں کیا جاتا۔ Raster تصاویر ایک نئی Design دستاویز شروع کر سکتی ہیں۔ وہ دستاویز موجودہ لائبریری اثاثہ ID استعمال کرتی ہے: Design کے پورے runtime اور URL path میں بالکل ورژن pins نافذ کرنا اب بھی الگ کام ہے۔ SVG/HTML/PDF/ZIP نتائج اس ہینڈ آف سے مبہم فائل اثاثوں کے طور پر رکھے جاتے ہیں، قابلِ اعتماد interactive/vector مواد میں ترقی نہیں دی جاتی۔
• Convert → Recent file operations ہسٹری کا استعمال، رپورٹس، ڈاؤن لوڈز اور ورژن مینیجر ظاہر کرتا ہے۔ مینیجر حذف شدہ لائبریری اثاثوں کے پرانے ورژنز بھی ڈھونڈ لیتا ہے۔ کسی اسنیپ شاٹ کو بحال کرنا منتخب اسنیپ شاٹ کو برقرار رکھتے ہوئے ایک نیا موجودہ ورژن بناتا ہے۔ سیٹنگز → اسٹوریج نتائج اور ورژنز کو ضائع ہونے والی کیشز سے الگ شمار کرتا ہے۔
• واضح temporary-file صفائی صرف operation کی ملکیت والے، غیر حوالہ شدہ بائٹس ہٹاتی ہے۔ موجودہ ریکارڈز اپنی فائلوں کی حفاظت کرتے ہیں؛ حالیہ OPFS فائلوں کو ایک گھنٹے کی grace period ملتی ہے۔ محفوظ شدہ نتائج اور اثاثہ اسنیپ شاٹس خودکار طور پر صاف نہیں کی جاتیں۔

پرانے readers اب بھی v2 envelope (minReader: 1) قبول کرتے ہیں اور مانوس حصے بحال کرتے ہیں، غیر معاون ہسٹری حصوں کو چھوڑے گئے کے طور پر شمار کرتے ہوئے۔ مکمل ہسٹری بحالی کے لیے fileHistory اڈاپٹر رکھنے والا شیل درکار ہے؛ یہ ایک شیل-اندرونی seam ہے، کوئی نئی ٹول کے سامنے آنے والی HostV1 صلاحیت نہیں۔ حقیقی دو-ڈیوائس بحالی مقامی Chromium گیٹ کے تحت آتی ہے؛ انسٹال شدہ Tauri/iOS/Android ریکوری قبولیت الگ رہتی ہے۔

کیا سفر نہیں کرتا

• کیٹلاگ کیشز (ڈاؤن لوڈ شدہ اثاثہ میٹا ڈیٹا اور بلابز، ٹول انڈیکس) - ٹارگٹ پر مفت میں دوبارہ سنک ہو جاتے ہیں۔
• کیٹلاگ ٹولز اور کیٹلاگ اثاثے - دائرہ کار سے باہر، اور فرض کیا جاتا ہے کہ یہ ٹارگٹ پر پہلے سے موجود ہیں۔ یوزر کے شامل کردہ برانڈ ٹوکنز، فونٹس اور لوگو یوزر اثاثے ہیں، اس لیے وہ سفر کرتے ہیں۔
• blob: / آبجیکٹ URLs - لوڈ کے وقت برج کے ذریعے دوبارہ تیار کیے جاتے ہیں۔
• کنورژن کے اصل، live execution leases اور مشین-مقامی رسائی/سائننگ سیکرٹس - پورٹیبل ہسٹری payload نہیں ہیں۔ ایک محفوظ شدہ نتیجہ ایک کاپی ہے، یہ وعدہ نہیں کہ اصل سورس کا بیک اپ لیا گیا تھا۔
• ایکسپورٹ سیکوئنس کاؤنٹر - فی-دن ڈاؤن لوڈ-نامنگ کاؤنٹر (localStorage کلید lolly-export-seq) ایک مقامی نامنگ سہولت ہے۔ اسے PREF_KEYS سے باہر رکھا جاتا ہے، لہٰذا یہ کبھی بنڈل میں شامل نہیں ہوتا۔

اسٹوریج میٹر اسی تقسیم کو تفصیل سے دکھاتا ہے۔ Saved sessions، My images اور File results & versions بنڈل میں شامل ہوتے ہیں۔ ان کے نیچے موجود اثاثہ کیش، ٹول پیش نظارے اور آف لائن پنز سب دوبارہ اخذ کیے جا سکتے ہیں، لہٰذا وہ پیچھے رہ جاتے ہیں۔

signed by Lolly2026-10-21vector SVG37 paths~4.9k nodes85 groups65 KBخود جانچیںدستخط شدہ فائل حاصل کریں signed by Lolly2026-10-21vector SVG37 paths~4.9k nodes85 groups65 KBخود جانچیںدستخط شدہ فائل حاصل کریں

کراس-شیل ضمانت

data-transfer.ts صرف capability bridge (host.profile، host.state، host.assets) اور مشترکہ localStorage prefs کے ذریعے پڑھتا اور لکھتا ہے۔ وہی ماڈیول ویب اور Tauri پر مشترکہ envelope پڑھتا اور لکھتا ہے، IndexedDB یا فائل سسٹم اسٹوریج پر۔ اختیاری ہسٹری حصے صرف وہیں ظاہر ہوتے ہیں جہاں متعلقہ اڈاپٹر دستیاب ہو؛ ایک غیر معاون حصہ امپورٹ پر چھوڑا گیا رپورٹ کیا جاتا ہے۔ Headless سویٹ مشترکہ حصوں کو ایک in-memory bridge کے خلاف آزماتی ہے، جبکہ ہسٹری transactions کے پاس حقیقی براؤزر ٹیسٹس بھی ہیں۔

دو shells اس ضمانت سے باہر ہیں، مختلف وجوہات کی بنا پر:

• one-shot CLI کے پاس لے جانے کو کچھ نہیں ہے - اس کی state ہر invocation کے لیے in-memory اور عارضی ہوتی ہے۔
• TUI state کو محفوظ ضرور کرتا ہے (~/.lolly: sessions، folders، profile) اور اس کا Profile view اس کا بیک اپ لے سکتا ہے، لیکن یہ اپنا ایک سادہ archive لکھتا ہے: ہر session کے لیے saved-state/<slot>.json نیز profile.json اور folders.json، بغیر کسی manifest کے، بغیر formatVersion/minReader اور بغیر integrity map کے۔ یہ اس فارمیٹ کے ذریعے قابلِ import نہیں - reader اسے "not a Lolly backup" کہہ کر رد کر دیتا ہے - اور الجھن کی بات یہ ہے کہ یہ ملتا جلتا نام استعمال کرتا ہے (lolly-backup-<stamp>.zip)۔ دونوں کو یکجا کرنا ایک معلوم خلا ہے۔

محفوظ توسیعی پوائنٹس

envelope بذاتِ خود ایک manifest اور نامزد parts کا مجموعہ ہے، تاکہ نئی طرح کی portable data بعد میں بغیر کسی breaking change کے اس پر سوار ہو سکے۔ یہ additive parts کے طور پر شامل ہوں گے (نیا formatVersion، وہی minReader)، اور آج کا reader جو نہیں پہچانتا اسے چھوڑ دیتا ہے۔ یہ ابھی نہیں بنائے گئے۔ نام یہاں محفوظ کیے گئے ہیں تاکہ جب یہ آئیں تو فارمیٹ مربوط رہے۔

• tokens.json - design tokens۔ ایک W3C DTCG design-tokens دستاویز (وہ فارمیٹ جسے Penpot import اور export کرتا ہے - $value/$type/$description والے tokens، جو groups، sets اور themes میں منظم ہوں)۔ bundle میں موجود token set صارف کو اپنے brand primitives کو اپنی sessions کے ساتھ ایک انسٹال سے دوسرے میں منتقل کرنے دیتا ہے۔ (صارف کے اپنے brand tokens آج بھی assets.json میں user/tokens/brand اثاثے کے طور پر سفر کرتے ہیں؛ یہ حصہ اپنے sets اور themes سمیت ایک مکمل DTCG دستاویز لے کر چلے گا۔) طویل مدت میں، ایک ingest شدہ token set ایک first-class ماخذ بن جائے گا جس کے خلاف tools اور palette assets resolve ہوں گے۔
• penpot/ - ingest شدہ Penpot فائلیں۔ ایک محفوظ directory ایک Penpot فائل (یا اس کے نکالے گئے، Lolly سے متعلقہ حصے) کے لیے جو ایک tool کے طور پر import اور ظاہر کی گئی ہو۔ bundle ingest شدہ definition کو لے کر چلے گا، تاکہ یہ صارف کے باقی ڈیٹا کے ساتھ سفر کرے۔

ان محفوظ ناموں اور اوپر دیے گئے parts کے علاوہ کچھ بھی reader کے نزدیک ایک نامعلوم part ہے: چھیڑا نہیں جاتا اور skipped میں شمار ہوتا ہے۔

حوالہ

• ماڈیول: shells/web/src/data-transfer.ts (exportBackup، importBackup، BACKUP_FORMAT، BACKUP_FORMAT_VERSION، BACKUP_READER_VERSION - backupFilename() نام دینے والا اندرونی ہے)۔
• Contract ٹیسٹ: tests/data-transfer.test.ts - round-trip، merge، integrity، forward-compat اور reader-gate کیسز۔
• ہسٹری Contract ٹیسٹس: tests/file-history-backup.test.ts، tests/file-batch-history.test.ts اور tests/file-result-library.test.ts۔ Browser acceptance: tests/file-history.browser.test.ts، tests/file-batch-history.browser.test.ts اور tests/file-result-reuse.browser.test.ts۔
• استعمال شدہ Bridge سطح: host.profile، host.state، host.assets - دیکھیے Host API۔