Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Who or what is polluting my external SD card?

571 views
Skip to first unread message

Danny D.

unread,
Aug 30, 2016, 12:04:47 PM8/30/16
to
I have a files directory on my SD card where I put everything but something
is polluting the top level of my sd card with junk.

I just deleted about twenty folders and what first came back were these.

1. .android_secure (an empty folder)
2. Android (contains a folder named data)
4. Android/data (contains three folders)
a. com.google.android.music/files/._playmusicid
b.
com.mapfactor.navigator/files/navigator/log/notifications_(number_date).log.txt
c. com.samsung.music/cache/
3. LOST.DIR

The odd thing is that I never even ran those apps nor do I use the external
SD card for anything other than storing some files. So WHO or WHAT is
creating all that trash on my SD card?

Why can't it put all that trash on the internal memory?

Roger Mills

unread,
Aug 30, 2016, 1:14:13 PM8/30/16
to
What version of Android are you using? If 6, is the SD card configured
as an extension of internal storage rather than as a removable device?
If so, the system will have put those folders there. If you delete them,
at worst the whole thing will stop working and at best, they'll simply
re-appear.

They're probably using next to no space, and are just place-holders.
--
Cheers,
Roger
____________
Please reply to Newsgroup. Whilst email address is valid, it is seldom
checked.

Danny D.

unread,
Aug 30, 2016, 11:30:39 PM8/30/16
to
On Tue, 30 Aug 2016 18:16:08 +0100, Roger Mills wrote:

> What version of Android are you using?

4.3

> If 6, is the SD card configured
> as an extension of internal storage rather than as a removable device?

As far as I remember, the SD card is just there.
It's not set up for anything.
It's just there.

I only use it for downloads mostly.

> If so, the system will have put those folders there. If you delete them,
> at worst the whole thing will stop working and at best, they'll simply
> re-appear.

They reappear.
Not all of them.
Just the stubborn ones reappear.

> They're probably using next to no space, and are just place-holders.

This is true that they're using almost zero space.
But they make my card ugly.

I like to keep it all clean and organized.

Roger Mills

unread,
Aug 31, 2016, 6:06:04 AM8/31/16
to
Looks like it insists on installing its default file structure on the
card. I guess you'll just have to live with it.

Danny D.

unread,
Aug 31, 2016, 11:47:03 PM8/31/16
to
On Wed, 31 Aug 2016 11:08:00 +0100, Roger Mills wrote:

> Looks like it insists on installing its default file structure on the
> card. I guess you'll just have to live with it.

I do live with it, and I can use a file redirector to move everything to a
junk directory but I was just trying to figure out WHY and WHO was
polluting my SD card.

Currently these are the pollutants:
1. LOST.DIR
2. Android
3. .android_secure

John B.

unread,
Sep 1, 2016, 3:10:05 AM9/1/16
to
LOST.DIR directory appears to be a normal part of he Android file
system and is added at the time the card is formatted.

The Android directory also seems to be a normal part of the file
system also. At least it appears after formatting the SD card on an
Android 5.0.1 phone.

The ".android_secure" is, I believe the folder/directory where apps
that are "Moved to SD Card" are stored.

--
cheers,

John B.

Danny D.

unread,
Sep 1, 2016, 2:45:09 PM9/1/16
to
On Thu, 01 Sep 2016 14:10:03 +0700, John B. wrote:

> LOST.DIR directory appears to be a normal part of he Android file
> system and is added at the time the card is formatted.
>
> The Android directory also seems to be a normal part of the file
> system also. At least it appears after formatting the SD card on an
> Android 5.0.1 phone.
>
> The ".android_secure" is, I believe the folder/directory where apps
> that are "Moved to SD Card" are stored.

I don't doubt anything you said, but I deleted everything but my data
folder, and within an hour, these additional folders were created, so, it's
not just created at the time of format.

I don't have any apps "moved to sd card" either.

So, while I don't dispute what you said, something is *creating* these
folders, and, in effect, "polluting" my SD card.

The lesson here is that pollution will occur, so, it makes no sense to put
stuff at the top level of the SD card. So I'll stick everything under data
and then delete periodically all the other top-level folders other than
data.

I have been doing similarly on Windows for decades, where I create a data
directory and put everything I want in there. That way, I can completely
delete the contents of Documents and Settings and I lose zero data that I
care about.

It's amazing to me how terrible operating system developers are at
organizing file systems.

Hergen Lehmann

unread,
Sep 1, 2016, 4:15:03 PM9/1/16
to
Am 01.09.2016 um 05:47 schrieb Danny D.:

> I do live with it, and I can use a file redirector to move everything to a
> junk directory but I was just trying to figure out WHY and WHO was
> polluting my SD card.
>
> Currently these are the pollutants:
> 1. LOST.DIR

This is part of the file system. If the file system stored on the card
gets damaged (for example due to a system crash), the device is supposed
to move recovered files into LOST.DIR during bootup.

> 2. Android

Starting with Android 4.4, write access to the SD card was restricted to
one dedicated directory for each application. These directories reside
below the "Android" folder.
Some Apps may store important data here, do not delete! You can easily
identify the culprit, because each subdirectory below Android is named
the same as the app id.

> 3. .android_secure

This is somehow used, when an App is "moved" to the SD card, but i don't
know the details.
If Android fails to mount an SD card, a corrupted .android_secure folder
is frequently the cause and deleting the folder may repair the card.

Hergen

John B.

unread,
Sep 2, 2016, 1:32:32 AM9/2/16
to
On Thu, 1 Sep 2016 18:45:08 -0000 (UTC), "Danny D."
<dannyd...@yahoo.com> wrote:

>On Thu, 01 Sep 2016 14:10:03 +0700, John B. wrote:
>
>> LOST.DIR directory appears to be a normal part of he Android file
>> system and is added at the time the card is formatted.
>>
>> The Android directory also seems to be a normal part of the file
>> system also. At least it appears after formatting the SD card on an
>> Android 5.0.1 phone.
>>
>> The ".android_secure" is, I believe the folder/directory where apps
>> that are "Moved to SD Card" are stored.
>
>I don't doubt anything you said, but I deleted everything but my data
>folder, and within an hour, these additional folders were created, so, it's
>not just created at the time of format.
>
>I don't have any apps "moved to sd card" either.
>
>So, while I don't dispute what you said, something is *creating* these
>folders, and, in effect, "polluting" my SD card.

As I said, a normal part of the file system :-)
the file system.

>The lesson here is that pollution will occur, so, it makes no sense to put
>stuff at the top level of the SD card. So I'll stick everything under data
>and then delete periodically all the other top-level folders other than
>data.

What do you gain by that? An empty file or directory occupies only a
few bytes and you say that if deleted they reappear in an hour. It
sounds like an exercise in futility :-)


>I have been doing similarly on Windows for decades, where I create a data
>directory and put everything I want in there. That way, I can completely
>delete the contents of Documents and Settings and I lose zero data that I
>care about.
>
>It's amazing to me how terrible operating system developers are at
>organizing file systems.

Quite the contrary. They are very good at organizing file systems...
to fit their needs or notions. The fact that you do not agree doesn't
make it a bad file system.

--
cheers,

John B.

Bob Martin

unread,
Sep 2, 2016, 2:34:41 AM9/2/16
to
That's an incredibly arrogant and conceited attitude.

Piet

unread,
Sep 2, 2016, 3:41:28 AM9/2/16
to
John B. wrote:
> "Danny D." wrote:
>> It's amazing to me how terrible operating system developers are at
>> organizing file systems.
>
> Quite the contrary. They are very good at organizing file systems...
> to fit their needs or notions.

That's inflexible, not necessarily good, and often a nuisance.

-p

John B.

unread,
Sep 2, 2016, 5:13:16 AM9/2/16
to
But, how does one design a computer operating system without
establishing a file system :-)
--
cheers,

John B.

Danny D.

unread,
Sep 3, 2016, 3:26:57 AM9/3/16
to
On Fri, 02 Sep 2016 07:34:40 BST, Bob Martin wrote:

>>It's amazing to me how terrible operating system developers are at
>>organizing file systems.
>
> That's an incredibly arrogant and conceited attitude.

I know far too much about organizing data to be respectful of the
absolutely sophomoric attitude most developers have toward a clean file
system hierarchy.

If you want, I'll post pictures of my Windows setup, but rest assured, it's
ORGANIZED.

I only maintain a single desktop screen on Android, and rest assured, it's
probably the most well organized desktop of anyone in this thread.

In fact, I'd wager it's better organized conceptionally than 99 percent of
the people on earth who "claim" to have their desktop organized.

I can explain exactly why everything is where it is as they *all* follow a
similar pattern (and I have hundreds of apps - none of which are more than
a click or two away).

I save *all* the data I want in a well-organized data hierarchy and I use a
file redirector to make up for the sheer and utter stupidity of most app
developers when it comes to allowing the user to put data where it belongs.

Nothing whatsoever is ever organized by brand name.
Everything is organized by what the data does.

I have worked in the software industry for three decades.
While app developers are smart, one thing they are NOT is well organized as
a whole and as a team. They put their crap EVERYWHERE.

They don't care.
Just like you don't seem to care nor did most of the respondents above seem
to care how things are organized, app developers are even worse organized
than you are.

And that's the problem.
It's not arrogance you see in me; it's knowledge.

I know they don't care one whit about adhering to a well-organized file
system.

And I lament that obvious fact.
The proof is in the taste of the pudding.
Just *look* at the horrid mess that is the Android file system in practice!

Danny D.

unread,
Sep 3, 2016, 3:27:03 AM9/3/16
to
On Fri, 02 Sep 2016 16:13:15 +0700, John B. wrote:

> But, how does one design a computer operating system without
> establishing a file system :-)

If god had put me in charge of *any* operating system, I would implement a
rule that there would be three simple areas, by definition, and that all
apps would have to respect the concept (including the os apps).

1. An area for the operating system to pollute.
2. An area for the apps to pollute.
3. A pristine area for the user to store desired data.

Danny D.

unread,
Sep 3, 2016, 3:27:09 AM9/3/16
to
On Fri, 2 Sep 2016 09:41:26 +0200, Piet wrote:

> That's inflexible, not necessarily good, and often a nuisance.

Android, IMHO, should have a directory for apps, and all the "crap" created
by an app should go there, period. That directory should never contain
stuff the user specifically wants to save by manual action; it should only
contain crap that apps do in the business of being apps.

Then, Android, IMHO, should have a directory for operating system crap,
under the same logical rules. Anything the operating system wants to
create, it puts under that android-crap directory.

Then, there should be a directory for user data. That's stuff like saved
maps, gpx tracks, contacts vcf files. This is where all apps should default
to put user-desired data.

Just as absolute power corrupts, all app developers get corrupted in that
they want *their* crap in the user-defined data directory. It always
happens, so, the rule should be that NO APP puts anything in the
user-defined data directory unless the user himself *changes* a setting
which allows the app to put crap in the user data directory.

The only reason for that last rule is that all app developers become
corrupted by the power to pollute the users' pristine area simply because
pristine areas are like empty flat space in a packrat's home.

Everyone wants to pollute the empty flat space.

Danny D.

unread,
Sep 3, 2016, 3:27:21 AM9/3/16
to
On Fri, 02 Sep 2016 12:32:30 +0700, John B. wrote:

>>So, while I don't dispute what you said, something is *creating* these
>>folders, and, in effect, "polluting" my SD card.
>
> As I said, a normal part of the file system :-)
> the file system.

If I had another life to live, I would have asked god to put me in charge
of designing the filesystem structure of Microsoft, Linux, and Android
devices, at the time they were being developed.

For Android, I would have designated a *single* directory (much like
Microsoft tries to do with C:\Windows - but fails overall in doing) where
all the file-system crap would go.

So, if there *must* be a directory on Android, it would be alphabetically
low (so it sorts as last) and hidden most of the time.

Dunno what I'd call it, but something like ".!android" or whatever sorts
low on the list and is hidden.

Then I'd make a rule that *everything* that is autogenerated by the OS must
go there, so that the user only has to deal with one idiotic directory.

> What do you gain by that? An empty file or directory occupies only a
> few bytes and you say that if deleted they reappear in an hour. It
> sounds like an exercise in futility :-)

I'm looking at it from the standpoint of putting files and directories at
the top level - which - because of the indeterminant pollutants - I can't
do because I can never be sure if I created the file or directory by a
program that I care about, or if Android did.

You are not looking at it as a litter pollutant.
To you, it's not an eyesore, and, to you, sorting out what is litter and
what is valuable isn't a problem.

I understand that.

You are looking at it as just an empty directory (just like the makers of
Windows looked at
c:\{boot.ini,boot.bak,cmldr,config.sys,io.sys,msdos.sys,ntdetect.com,ntldr}
as just a bunch of small files.

But "I" look at it as pollutants of my root directory.
Why on earth couldn't they stick those files in a single directory?

Worse - on Windows for example, your START menu is polluted by every
program you install. So you're forced to create your own menu, which works
perfectly since nothing pollutes it - but that also makes the initial start
menu useless.

The rule should have been, IMHO, from the start, to prevent that. I can
think of a few ways but the vast majority of people are too stupid to
prevent the mess. So they can no longer find anything in their start menu
even though a start menu is a FANTASTIC way to run programs if it's
unpolluted. (My start menu, for example, is perfect.)

Even worse, the Documents and Settings hierarchy is so filled with
pollutants that it's basically almost useless to the user, as a top-level
directory. That's bad for backup purposes and for organizational purposes.

Anyway, Android went the same way as Windows. Same concept of polluting
*everything* it touches, including the SD card (which really, should have
nothing to do, per se, with Android polluting it).

I'm ok with a single point of pollution if they must pollute an SD card.

>>I have been doing similarly on Windows for decades, where I create a data
>>directory and put everything I want in there. That way, I can completely
>>delete the contents of Documents and Settings and I lose zero data that I
>>care about.
>>
>>It's amazing to me how terrible operating system developers are at
>>organizing file systems.
>
> Quite the contrary. They are very good at organizing file systems...
> to fit their needs or notions. The fact that you do not agree doesn't
> make it a bad file system.

I understand your point that, to you, Android littering files and
directories willy nilly all over both the internal and external storage is
"organized" by "their" (horrid) standards.

To me, if they really were "organized", they'd put all their litter in a
single directory, instead of polluting everything everywhere. I'm sure
you've perused the Android file system on the internal sd storage, and you
must be aghast (as I am) at the utter incomprhensible mess that Android
does to the file system.

AM I not right?

I mean, look at slash (/) in the Android file system!
It's a royal mess.
Worse than Windows.
Even worse than Linux (which at least *tried* to be organized!).

Nothing follows any rules.
It should be so simple that anyone can figure it out.

/apps/(all apps *must* install their pollution here)
/data/ (all apps must store their user-saved data here!)
NOTE: User-saved data is not the same as app-pollution data!
(Most app developers can't fathom that there is a distinction!)
/android/ (all android OS crap goes here)


John B.

unread,
Sep 3, 2016, 4:40:28 AM9/3/16
to
Perhaps you might try an operating system other than Windows? To my
knowledge Unix, Linux and the Apple look alike all allow the user to
define and control areas for various purposes. You can, for example,
have a Data directory that allows only the User to access, while the
operating system has its own areas.

This isn't new nor is it rocket science, after all Unix dates to the
1970's

Oh yes, Android, being at least partially based on Linux allows the
same thing... if you know how to arrange it.
--
cheers,

John B.

Piet

unread,
Sep 3, 2016, 4:42:42 AM9/3/16
to
Danny D. wrote:
> 1. An area for the operating system to pollute.
> 2. An area for the apps to pollute.
> 3. A pristine area for the user to store desired data.

4. A pristine area for the user to store undesired data.
Also known as Trash or Junk.
;-)

-p

Hergen Lehmann

unread,
Sep 3, 2016, 4:45:02 AM9/3/16
to
Am 03.09.2016 um 09:27 schrieb Danny D.:

> Android, IMHO, should have a directory for apps, and all the "crap" created
> by an app should go there, period. That directory should never contain
> stuff the user specifically wants to save by manual action; it should only
> contain crap that apps do in the business of being apps.

Actually, Android has such a rule. For each app, there are two dedicated
directories (one in internal storage and one on external SD card)
reserved for application-internal data.

But then, there's also the directory where user data is supposed to go.
Unfortunately, there is no strict definition, what "user data" is. And
unfortunately, no one can prevent an app to store something else there, too.

> Then, Android, IMHO, should have a directory for operating system crap,
> under the same logical rules. Anything the operating system wants to
> create, it puts under that android-crap directory.

There is such a directory (/data in internal storage, /.android_secure
on SD card).

> Then, there should be a directory for user data. That's stuff like saved
> maps, gpx tracks, contacts vcf files. This is where all apps should default
> to put user-desired data.
>
> Just as absolute power corrupts, all app developers get corrupted in that
> they want *their* crap in the user-defined data directory. It always

This is not always the developer's fault. In early android days, app
data storage was *VERY* limited (only a few 100MB in total!), and it
still is quite limited on many entry-level phones.

If a developer wants his app to run on such devices, he has no choice,
but to put larger chunks of data into the user data area and especially
onto the external SD card. Yes, there is the dedicated directory
mentioned above - but this was not available before android 4.4 and
there are still too many devices out there running older versions.
Again, if the developer wants to reach as many users as possible, he is
forced to put larger chunks of data into the user data area.

> happens, so, the rule should be that NO APP puts anything in the
> user-defined data directory unless the user himself *changes* a setting
> which allows the app to put crap in the user data directory.

This would surely be too much to ask for the average user. He/she just
wants to play that damn game app. If that fails because the app does not
have enough memory to store its maps and ads, the app and/or phone will
be considered broken.

Hergen

Danny D.

unread,
Sep 3, 2016, 5:42:41 AM9/3/16
to
On Sat, 03 Sep 2016 15:40:25 +0700, John B. wrote:

> Perhaps you might try an operating system other than Windows?

I'm very familiar with Linux and Windows and not at all familiar with Mac
(OSX).

I'm also very familiar with iOS and ANdroid.

> To my
> knowledge Unix, Linux and the Apple look alike all allow the user to
> define and control areas for various purposes.

Of the operating systems that I'm familiar with, only iOS is so limited
that you can't easily define and control areas for various purposes.


> You can, for example,
> have a Data directory that allows only the User to access, while the
> operating system has its own areas.

Notice that this is the *entire* point of this thread.
You can have a data *directory* - but you can't (apparently) have an *sd
card*.

That's the whole point of the thread.
I wanted an unpolluted sd card.

You can't have that (apparently).
You can only have an unpolluted directory.

> This isn't new nor is it rocket science, after all Unix dates to the
> 1970's

I used Unix since when it was VMS and sunos (but not in the 70's).

> Oh yes, Android, being at least partially based on Linux allows the
> same thing... if you know how to arrange it.

The revelation here is that Android pollutes the *sd card*.
Android does not pollute the data *directory*.

I'm ok with a single point of pollution if they must pollute an SD card.
But I am not ok with *multiple* points of pollution.

If they simply thought ahead (and if they cared), they'd create a
"androidcrap" directory (the name is irrelevant other than it should sort
low on the list) for all pollutants.

Danny D.

unread,
Sep 3, 2016, 5:42:43 AM9/3/16
to
On Sat, 3 Sep 2016 10:38:51 +0200, Hergen Lehmann wrote:

> Actually, Android has such a rule. For each app, there are two dedicated
> directories (one in internal storage and one on external SD card)
> reserved for application-internal data.

Except that those two directories pollute the *top* level of the storage
space (whether internal or external).

Is that correct?

That is, they go into:
/(internalstorage)/MYAPPNAME1/myappcrap
/(internalstorage)/MYAPPNAME2/myappcrap
/(internalstorage)/MYAPPNAME3/myappcrap
and
/(externalstorage)/MYAPPNAME1/myappcrap
/(externalstorage)/MYAPPNAME2/myappcrap
/(externalstorage)/MYAPPNAME3/myappcrap

Instead, they should go into a dedicated directory, just like your words
stated. The name of that dedicated directory could be anything, but here's
an illustrative example:
/(internalstorage)/appcrap/MYAPPNAME{1,2,3}/myappcrap
/(externalstorage)/appcrap/MYAPPNAME{1,2,3}/myappcrap

> But then, there's also the directory where user data is supposed to go.
> Unfortunately, there is no strict definition, what "user data" is. And
> unfortunately, no one can prevent an app to store something else there, too.

It's a fair statement that it's not always clear what user data is.
For a camera, it's generally pretty clear that photos and videos are user
data, but, for a map app one could argue whether the offline maps and POIs
are user data, while certainly a GPX track is user data.

Also, one could argue whether saved 'settings' are user data.

That's why I would enforce that the *user* defines what is user data.
No app would ever put stuff in the user directory unless the user set the
setting to do that and even then, the actual directory should be wholly
under the users' control.

>> [3 quoted lines suppressed]
>
> There is such a directory (/data in internal storage, /.android_secure
> on SD card).

Then why do I have all that crap on my sd card outside of .android_secure?
(note that I have Android 4.3 and I see that you said below that things
changed in Android 4.4)

>> [6 quoted lines suppressed]
>
> This is not always the developer's fault. In early android days, app
> data storage was *VERY* limited (only a few 100MB in total!), and it
> still is quite limited on many entry-level phones.
> If a developer wants his app to run on such devices, he has no choice,
> but to put larger chunks of data into the user data area and especially
> onto the external SD card. Yes, there is the dedicated directory
> mentioned above - but this was not available before android 4.4 and
> there are still too many devices out there running older versions.
> Again, if the developer wants to reach as many users as possible, he is
> forced to put larger chunks of data into the user data area.

This is interesting information. Thank you.

>> [3 quoted lines suppressed]
>
> This would surely be too much to ask for the average user. He/she just
> wants to play that damn game app. If that fails because the app does not
> have enough memory to store its maps and ads, the app and/or phone will
> be considered broken.

Defaults are fine as long as the user directory is never polluted unless
the user expressly and manually allows it.

Danny D.

unread,
Sep 3, 2016, 5:42:44 AM9/3/16
to
On Sat, 3 Sep 2016 10:42:41 +0200, Piet wrote:

> 4. A pristine area for the user to store undesired data.
> Also known as Trash or Junk.

Heh heh ... in many ways, that's (cynically) true.

One problem is that *most* users don't have a clue how to organize their
file system.

And, since I have never found a developer who knows how to organize a file
system, the user generally follows the horrid system that the operating
system allows by default.

So it's almost always a mess - unless the user knows himself how he wants
his file system organized.

Hergen Lehmann

unread,
Sep 3, 2016, 7:45:03 AM9/3/16
to
Am 03.09.2016 um 11:42 schrieb Danny D.:

>> Actually, Android has such a rule. For each app, there are two dedicated
>> directories (one in internal storage and one on external SD card)
>> reserved for application-internal data.
>
> Except that those two directories pollute the *top* level of the storage
> space (whether internal or external).
>
> Is that correct?

No.

> That is, they go into:
> /(internalstorage)/MYAPPNAME1/myappcrap
> /(internalstorage)/MYAPPNAME2/myappcrap
> /(internalstorage)/MYAPPNAME3/myappcrap

The locations proposed by the android API are actually:

/data/data/<appid>/myappcrap
(for internal app data)

/<internalstorage>/Android/data/<appid>/myappcrap
(for app data on tablets using the multi-user feature, with
<internalstorage> actually being located at "/data/media/<userid>" alias
"/storage/emulated/<userid>" alias "/sdcard").

/<externalstorage>/Android/data/<appid>/myappcrap
(for app data on external storage)

Apps developed since the 4.4 era should generally stick to that
structure, otherwise they will get serious problems on multi-user
devices and when trying to access the external storage.

> Instead, they should go into a dedicated directory, just like your words
> stated. The name of that dedicated directory could be anything, but here's
> an illustrative example:
> /(internalstorage)/appcrap/MYAPPNAME{1,2,3}/myappcrap
> /(externalstorage)/appcrap/MYAPPNAME{1,2,3}/myappcrap

That's exactly, what google proposes. :-P

> It's a fair statement that it's not always clear what user data is.
> For a camera, it's generally pretty clear that photos and videos are user
> data, but, for a map app one could argue whether the offline maps and POIs
> are user data, while certainly a GPX track is user data.
>
> Also, one could argue whether saved 'settings' are user data.

Exactly.

> That's why I would enforce that the *user* defines what is user data.

Again, this would certainly be too much to ask of the average user. Most
users are not even capable of deciding, whether a game should have
access to their personal data. The just say "yes" to everything, that
cool app asks for.

> Then why do I have all that crap on my sd card outside of .android_secure?
> (note that I have Android 4.3 and I see that you said below that things
> changed in Android 4.4)

This may be part of the reason. Things get cleaner on newer versions, at
least for external storage. Unfortunately, there is still nothing that
enforces the developers to stick to the conventions on internal storage.

Hergen

John B.

unread,
Sep 4, 2016, 12:41:01 AM9/4/16
to
VMS was a Digital Equipment Corporation operating system used on the
VAX 11 and other computers, and dates to 1977. Unix was developed by
the telephone company starting in 1969 and first used by the company
in 1971... When was Unix called VMS as you seem to assert.


>> Oh yes, Android, being at least partially based on Linux allows the
>> same thing... if you know how to arrange it.
>
>The revelation here is that Android pollutes the *sd card*.
>Android does not pollute the data *directory*.
>
>I'm ok with a single point of pollution if they must pollute an SD card.
>But I am not ok with *multiple* points of pollution.
>
>If they simply thought ahead (and if they cared), they'd create a
>"androidcrap" directory (the name is irrelevant other than it should sort
>low on the list) for all pollutants.
--
cheers,

John B.

Piet

unread,
Sep 4, 2016, 8:05:12 AM9/4/16
to
John B. wrote:
> "Danny D." wrote:
>> I used Unix since when it was VMS and sunos (but not in the 70's).
>
> VMS was a Digital Equipment Corporation operating system used on the
> VAX 11 and other computers, and dates to 1977. Unix was developed by
> the telephone company starting in 1969 and first used by the company
> in 1971...

Right. VMS was, eh... well:
http://www.netfunny.com/rhf/jokes/92q1/hrdvms.html

-p

Arno Welzel

unread,
Sep 4, 2016, 1:18:36 PM9/4/16
to
Danny D. schrieb am 2016-08-30 um 18:04:

> I have a files directory on my SD card where I put everything but something
> is polluting the top level of my sd card with junk.

Why you call it "junk"? Just because you don't want it?

> I just deleted about twenty folders and what first came back were these.
>
> 1. .android_secure (an empty folder)

.android_secure folder contains files of the apps which you moved to SD
card.

> 2. Android (contains a folder named data)
> 4. Android/data (contains three folders)

Similar to .android_secure, also contains data of apps which use the SD
card.

> a. com.google.android.music/files/._playmusicid
> b.
> com.mapfactor.navigator/files/navigator/log/notifications_(number_date).log.txt
> c. com.samsung.music/cache/

Ask the creators of the Apps (Google Music, Mapfactor Navigator).

> 3. LOST.DIR

Linux standard folder for the results of file system checks in case the
card wasn't properly unmounted before removing it from the slot or when
the system crashed without unmounting the file systems first.

> The odd thing is that I never even ran those apps nor do I use the external
> SD card for anything other than storing some files. So WHO or WHAT is
> creating all that trash on my SD card?
>
> Why can't it put all that trash on the internal memory?

Because the system isn't designed that way. Live with it. I wouldn't
bother as long as the system works without any errors.


--
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

tlvp

unread,
Jan 17, 2017, 1:57:35 AM1/17/17
to
On Sun, 04 Sep 2016 11:40:58 +0700, John B. wrote:

> When was Unix called VMS as you seem to assert.

I think he's recalling a garbled version of the Unix Multics story :-) .
Multics was a DEC project, as was VMS, whence the confusion.

HTH. Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.
0 new messages