PS This experience is specifically why I unhumbly advocate using UUIDs wherever possible, but that's fodder for another thread. :)
Good morning! Am reposting my response to Gary Dale's thread and am including a followup to help others duplicate the effect. The more I think on it, the same.... confusion is now coming back to mind as when I first encountered this. It *feels like* this is an area that could easily cause all KINDS of consistencies trouble, BUT admittedly, perhaps it's something that has long ago been addressed by Debian's intelligence in understanding its users' needs and computing (including hardware) quirks. Gary had inquired about missing hard drive space that he couldn't track down. I first replied by sharing my experience where phantom directories (representing missing partitions) were created on the fly by rsync and potentially in cahoots with my Debian copy. In the end, those on-the-fly "phantom" directories were understandably not recognized properly. e.g. unmounted nor indexed, by Debian. They became a permanent, non-disappearing fixture that progressively and very silently was eating up hard drive space:: On 2/11/16, Cindy-Sue Causey <butterflyby...@gmail.com> wrote: > > A Life Lesson Learned the [Abject Poverty] Way was.... one spot to always > check (for missing hard drive space) is... under /media/[user]... > > I'd been meaning to write it up. Seems like I had at least one other > thought about it, too, but that escapes me just now. > > So what had happened was... In my instance(s), it was a combination of > rysnc and a faulty USB connection for an external hard drive. Rsync > would just create a new target instead of complaining that one I > wanted didn't exist (because the USB connection had just once again > failed).. > > Since I was copying to that external hard drive, > /media/elf/data-partition/copied-files-directory was where it was > going. When rsync couldn't find that (because the USB connection had > just once again failed), rsync simply created that... SOMEHOW on my > primary hard drive under /media/elf. > > Took a couple months before I discovered it had been happening. That > occurred when I by accident noticed something called > /media/elf/data-partition_....... > > And /media/elf/data-partition__ > > AND /media/elf/data-partition___ > > Flailing around on my hard drive, all ONLY visible and accessible > directly under /media. > > The additional "__" and "___"? Created k/t a mix of how both rsync and > my Debian (likely Jessie as testing then) were trying to accommodate > my scenario. > > The secondary issue became that my Debian very quietly began mounting > the (faulty USB) external hard drive by adding its own "_"(s) once the > original /media/elf/data-partition name became permanently "mounted" > under /media. Apparently addending an upward number of "_" is, or at > least was, part of renaming nomenclature done on the fly if something > already appears under /media. > > Moral of the Story is that hard drive space was very quietly being > eaten alive while that was going on in a place we don't normally > visually inspect... and that space usage also was not being reflected > numerically via any utility tool package I knew to run at that moment. > > See why I hadn't tried to write it up yet? *grin!* And now the followup: Didn't think to check until after sending the original. For anyone interested, I just duplicated the effect by simply manually adding an empty directory under /media/elf. The name must be what you anticipate for a partition that's about to mount for real. I didn't mount the newly created directory name, just added it then connected my external USB hard drive. Slightly different results these days. Disclaimer there is that it might be because I'm using Thunar via Xfce4. Instead of adding "_", I'm seeing "1" added to the newly mounted directory name (that otherwise duplicates one Debian sees as pre-existing under /media/[user]. Actually thinking ahead THIS time, I unmounted the real partition, manually now created "data-partition01" under /media/elf. Remounted the original (real) data-partition0" and... "/media/elf/data-partition02" was spawned (as anticipated) because, in my system's eye, /media/elf/data-partition0 and /media/elf/data-partition01 appear to already be in use. Again, the reason for doing this at all is because one, no actually, two packages *were* doing exactly that on their own at some point. This isn't because I just one day got the bright idea to see what happens when a user throws a new manually created directory under /media/[user]. :) Anyway... This morning, I'm only seeing "data-partition0" in Thunar's leflhand DEVICES column. The stairstepping effect of gradually added "_"(s) during my original experience with this was noticed in that column. It was only overlooked originally because that column was so cluttered (by my over usage) back then. This so far only being visible under /media/[user] and not under that in-your-face lefthand DEVICES category in Thunar is a BIG change. It becomes even more obscure that way. *ouch, grin* The beauty of the spawning effect using numbers instead of underscores, "_", is that the directory names remain shorter. That makes them MUCH easier to distinguish that trying to count underscores, grin. BUT... knowing my own brain's method of operation, that change still leaves it as an easy error to overlook for a different reason on the first few run throughs. Just how it is. :) All the above now finally having been said out loud, a question occurs to me. Did I find something worth noting elsewhere, or is this something that is accepted as business as usual? For the record to document that progress has already been made, rsync at some point afterward addressed its part in the above. To verify, I just attempted an rsync to a non-existent partition and received back the following error: "rsync: change_dir#3 "/media/elf/data-tbxy" failed: No such file or directory (2) rsync error: errors selecting input/output files, dirs (code 3) at main.c(712) [Receiver=3.1.1]" That error shows that these days rsync does at the very least acknowledge and address the fatally missing directory path. If any other program packages still automatically create their own paths under /media instead of aborting and complaining about non-existent ones, the snowballing effect is.... extensive. :) Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with empty pail because her water line is frozen *
