XPost: comp.mobile.android, alt.comp.os.windows-10   
   From: marion@facts.com   
      
   On Sat, 1 Feb 2025 16:34:03 +0100, Janis Papanagnou wrote :   
      
      
   > (I probably shouldn't engage in this thread - and not only because it   
   > got aggressive recently   
      
   Kenny McCormack is the obvious off-topic troll whom you can thank for that.   
      
   When you throw out Kenny McCormack's trolling, you can then notice this   
   thread is about elegant planning, years ahead, for Windows playing a key   
   role in migrating Android editors from one device (or card) to another.   
      
   > - because it seems (partly?) a Windows issue,   
   > given the mention of 'C:', 'D:'   
      
   The idea is brilliant - as it involves migrating Android file editors years   
   ahead of time using the key features that Windows possess.   
      
   > and such crap later in this thread;   
   > but I'm curious...)   
      
   Other than Kenny McCormack's purposefully unhelpful common trolling, there   
   is no 'crap' here.   
      
   In fact, there are 3 exquisitely related issues, which most people (likely)   
   don't realize (perhaps) because most people haven't (apparently) ever even   
   once in their lives bothered to plan years ahead for platform migration,   
   particularly how Windows plays a role in migrating Android editors.   
      
   > First, the above mentioned IDs have a purpose, I think; to uniquely   
   > *identify* a hardware device.[*] (Please correct me if I'm wrong.) -   
      
   In another post in this thread, outside of Kenny McCormack's childish   
   trolling that is, we covered in gory detail the 3 sd card identifiers,   
   their (stated) purpose & on which platforms you can change them.   
    1. Volume ID (CID)   
    2. Volume Serial Number   
    3. Volume Name (aka Volume Label)   
      
   Bear in mind the enticing goal isn't to just change them, which I'm sure   
   everyone except that common troll understood, but to ensure a clean   
   migration years in the future for the files that Android editors edit.   
      
   > So it therefore sounds strange to change that ID in the first place.   
   > And therefore it wouldn't appear to me to re-label that device and   
   > even less to reformat the device just to change its "label".[**]   
      
   In stark contrast to Kenny McCormack's purposefully disruptive repetitive   
   attempts at common trolling, it's refreshing you are intelligently   
   inquiring as to WHY (almost) everyone who owns Android with an sdcard (&   
   who owns Windows plus a few Android editors) would greatly benefit from   
   changing the Volume Name (also well known completely interchangeably as the   
   Volume Label).   
      
   > What I typically see as "solution" - but which is rather more of a   
   > "concept" - is to use generic path components where you want them;   
   > on Unix-like systems you'd create for example a symbolic link like   
   >   /storage/generic -> /storage/A2B2-C2D2   
   > and generally access the files only through the generic link   
   >   /storage/generic/{editors}/{files}   
   > If you want to replace the storage device just re-link the generic   
   > link to the new device (and without any necessity to change device   
   > identity).   
      
   This was brought up prior, I think by Carlos if I remember correctly, where   
   I restrained myself from incredulously asking HOW he proposed to do that   
   symlinking on Android such that the all-important Android file editors   
   would still recognize a path that has completely changed out from under   
   them.   
      
   To be clear, I'm absolutely and emphatically NOT saying it can't be done;   
   nor am I even intimating that it's not a great idea - I'm only asking, eyes   
   wide open with intrigue, HOW you (and Carlos) would accomplish that.   
      
   To put that in layman's terms:   
   Q: How do you make a symlink on Android such that swapping out a 64GB   
      sd card with a 128GB sdcard won't affect where that Android editor   
      "thinks" it stored its files (when the sdcard Volume Name/Label is   
      suddenly completely different)?   
   A: ?   
      
   If you can propose HOW I can test that out, I'd be glad to test it.   
    a. Linux isn't the question (ln -s [target] [symlink])   
    b. Neither is Windows (mklink [[/D] | [/H] | [/J]]  )   
    c. The problem is non-root Android symlinks are problematic, are they not?   
      
   > (I'm not sure this is "clever" or "helpful" (as your suggestion is,   
   > according to your subject), but it appears much more sensible to me.   
   > Isn't that possible on Windows and Android to preserve portability?)   
      
   I like the idea of a non-root Android symlink, and, rest assured, that's   
   actually the very first idea that popped into my head (as it did for yours   
   and for Carlos' apparently).   
      
   So we all leaning toward what may be a rather profound global solution.   
   But the problem with creating symlinks on non-rooted Android is well known.   
      
   Android apps can usually create symlinks within their own data directories,   
   so if you know of such Android file editors, please let us all know.   
      
   But symlinking inside of every Android file editor isn't really elegant.   
   For a more global elegant solution, certainly we could strive to use "the   
   ln -s command in the adb shell, but that's fraught with difficulties due to   
   Android file system restrictions, especially in areas like /system or /data   
   which have strict permissions preventing symlinks in protected areas.   
      
   > [*] I, and the OS, should actually have an interest to know whether   
   > there's another (or new) device in the system.   
      
   Ah. You bring up an excellent (and rather astute) intelligent point as to   
   WHY the sd card happens to have three different identifiers, by default!   
      
   Bearing in mind that there are 3 identifiers of merit in this discussion   
    1. Volume ID (CID) is assigned by the OEM & is not changeable by the user   
    2. Volume Serial Number is uniquely created during the formatting process   
    3. Volume Name (aka Volume Label) is *intended* to be changed by the user   
      
   Certainly, it's well known that the Serial Number is the primary identifier   
   that the operating system is "expected" to know about & take into account.   
      
   And just as certainly, the whole point of the Volume Name (aka Volume   
   Label) is to perform the elegant task that was initially suggested in this   
   thread.   
      
   Note you can change the Volume Serial Number, but I'm not aware of an   
   Android editor that makes use of that Volume Serial Number, so why do it?   
      
   > [**] A quick browse of the Net shows that you could [on Windows] also   
   > just simply change that label by context menu 'properties'.   
      
   Let's be abundantly clear that we're not changing things simply for the   
   sake of changing them - but we're planning ahead - years ahead in fact -   
   for a migration so that Android editors can find their files which are   
      
   [continued in next message]   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)