Phantom Media Devices Created On The Fly (Was: disk space disappeared)
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 <butterflybytes@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 *
Reply to: