From Newsgroup: comp.sys.mac.system

Found a odd folder in /Library/Application Support.

each .dat file contains gibberish (no readable text).
Some files from 2020:
April 30,
May 18
August 25

But one from:
May 27 2021

Any chance these would be legit (fearing some license files for Adobe
products that are stored in non obviosu places) or are these nefarous
and should be deleted?

(I wish there were a feature like on VMS where you could set an alarm
whenever a file is accessed so I could know when and more importantly
which process opens to read or write such a file).


bike:Application Support $ ls -l 54F3DE4E-B7BA-4EBD-8B3B-385D272CC583/
total 200
-rwxrwxrwx 1 root admin 16 Apr 30 2020 0186a991.dat
-rwxrwxrwx@ 1 root admin 64 Aug 25 2020 0f5d21a3.dat
-rwxrwxrwx 1 root admin 64 Aug 25 2020 164610e2.dat
-rwxrwxrwx 1 root admin 16 Apr 30 2020 189d98d0.dat
-rwxrwxrwx 1 root admin 48 May 27 00:20 1f94300c.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 42630de3.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 61412074.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 694e5e20.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 6f9aa846.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 70556f61.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 76819907.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 785a1135.dat
-rwxrwxrwx 1 root admin 1264 Aug 25 2020 802dfb15.dat
-rwxrwxrwx 1 root admin 80 Aug 25 2020 8846e984.dat
-rwxrwxrwx 1 root admin 16 Apr 30 2020 8ef67327.dat
-rwxrwxrwx 1 root admin 0 Aug 25 2020 97ed4266.dat
-rwxrwxrwx 1 root admin 64 Aug 25 2020 9936ca54.dat
-rwxrwxrwx 1 root admin 64 May 18 2020 a5db20e4.dat
-rwxrwxrwx@ 1 root admin 1264 Aug 25 2020 ab00a8d6.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 d2dc1072.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 dc079840.dat
-rwxrwxrwx 1 root admin 0 Aug 25 2020 e0ea72f0.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 e63e8496.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 ee31fac2.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 f72acb83.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 f9f143b1.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 ff25b5d7.dat
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <Gq8wI.740208$nn2.140676@fx48.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

(I wish there were a feature like on VMS

then go use vms.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In message <Gq8wI.740208$nn2.140676@fx48.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

Found a odd folder in /Library/Application Support.

each .dat file contains gibberish (no readable text).
Some files from 2020:
April 30,
May 18
August 25

But one from:
May 27 2021

Any chance these would be legit (fearing some license files for Adobe products that are stored in non obviosu places) or are these nefarous
and should be deleted?

(I wish there were a feature like on VMS where you could set an alarm whenever a file is accessed so I could know when and more importantly
which process opens to read or write such a file).

Adobe is a large malware root kit, and no one knows what it does, but it spreads tentacles throughout your system. So sure, could be abobe.

bike:Application Support $ ls -l 54F3DE4E-B7BA-4EBD-8B3B-385D272CC583/

there is nothing suspicious about that path, it's simply a hash value.
They are not common in Application Support, but you will find similar
pattern files troughout your library.

$ find ~/Library | egrep "[0-9A-F]{8}-[0-9A-F]{4}-" | wc -l
160820

Yes, that is 160 thousand files or folders with the pattern of 8 hex
digits, a dash, 4 hex digits, and another dash.

Chances are that if you delete or move the folder, it will be recreated
by whatever app you have that uses it.

--
All Hell hadn't been let loose. It was merely Detritus. But from a
few feet away you couldn't tell the difference.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2021-06-09 19:14:45 +0000, JF Mezei said:

Found a odd folder in /Library/Application Support.

each .dat file contains gibberish (no readable text).
Some files from 2020:
April 30,
May 18
August 25

But one from:
May 27 2021

Any chance these would be legit (fearing some license files for Adobe products that are stored in non obviosu places) or are these nefarous
and should be deleted?

(I wish there were a feature like on VMS where you could set an alarm whenever a file is accessed so I could know when and more importantly
which process opens to read or write such a file).

bike:Application Support $ ls -l 54F3DE4E-B7BA-4EBD-8B3B-385D272CC583/
total 200
-rwxrwxrwx 1 root admin 16 Apr 30 2020 0186a991.dat
-rwxrwxrwx@ 1 root admin 64 Aug 25 2020 0f5d21a3.dat
-rwxrwxrwx 1 root admin 64 Aug 25 2020 164610e2.dat
-rwxrwxrwx 1 root admin 16 Apr 30 2020 189d98d0.dat
-rwxrwxrwx 1 root admin 48 May 27 00:20 1f94300c.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 42630de3.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 61412074.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 694e5e20.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 6f9aa846.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 70556f61.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 76819907.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 785a1135.dat
-rwxrwxrwx 1 root admin 1264 Aug 25 2020 802dfb15.dat
-rwxrwxrwx 1 root admin 80 Aug 25 2020 8846e984.dat
-rwxrwxrwx 1 root admin 16 Apr 30 2020 8ef67327.dat
-rwxrwxrwx 1 root admin 0 Aug 25 2020 97ed4266.dat
-rwxrwxrwx 1 root admin 64 Aug 25 2020 9936ca54.dat
-rwxrwxrwx 1 root admin 64 May 18 2020 a5db20e4.dat
-rwxrwxrwx@ 1 root admin 1264 Aug 25 2020 ab00a8d6.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 d2dc1072.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 dc079840.dat
-rwxrwxrwx 1 root admin 0 Aug 25 2020 e0ea72f0.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 e63e8496.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 ee31fac2.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 f72acb83.dat
-rwxrwxrwx 1 root admin 2 Apr 30 2020 f9f143b1.dat
-rwxrwxrwx 1 root admin 32 Aug 25 2020 ff25b5d7.dat

Get info on some of these provides no useful info? I have come to love Houdahspot for digging through my world.

I might look at "all files created" on Aug 25 to see if I could find a correlation.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2021-06-10 02:56:12 +0000, gtr said:

On 2021-06-09 19:14:45 +0000, JF Mezei said:

Found a odd folder in /Library/Application Support.

each .dat file contains gibberish (no readable text).
Some files from 2020:
April 30,
May 18
August 25

But one from:
May 27 2021

Any chance these would be legit (fearing some license files for Adobe
products that are stored in non obviosu places) or are these nefarous
and should be deleted?

(I wish there were a feature like on VMS where you could set an alarm
whenever a file is accessed so I could know when and more importantly
which process opens to read or write such a file).

<snip>

There are apps like FSMonitor which will tell you when a file is created.

Get info on some of these provides no useful info? I have come to love Houdahspot for digging through my world.

I might look at "all files created" on Aug 25 to see if I could find a correlation.

There's a lot of strange named files and folders within the two Library folders, especially deep inside various sub-folders. You'll never find
out what they belong to. You can thank MacOS X being based on Unix for
that (there were strangley named files and folders even in the
"Classic" MacOS System Folder, but nowhere near as many or so
widespread).


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

Another puzzling one, a behaviour I have not seen before.
High Sierra. Home directory on APFS SSD.


On my desktop:

.MG-9A44E1BB-6071-4B4...91546D
(icon is that of a vanilla document).

I cannot move it in Finder.
I cannot Alt move it to another folder to copy it. (to see what is
inside, how big it is).

If I move an item that is just to the right of the file, the mystery
file then moves right to the space vacated when I moved the other file.

I cannot Get Info for it. (no error message, but nothing happens).

If I try to delete it:
"The Item .MG-9A44E1BB-6071-4B43-B82D-D2828F91546D can't be moved to
the Trash because it can't be deleted. (only button is OK)

If I open a finder window to "Desktop", the file isn't there (but then
again, I think Finder tends to hide any/all . files) imilarly, Time
Machine does not show the file.

In command line:
ls -a ~/Desktop does not show the file
ls -a ~/Desktop/.MG* does not show the file

I can't run disk first first air without logging off. I get a feeling
that there is an entry in the GUI file that contains desktop description
and file positions, but that entry doesn't poinr to a file.

or is there a way to hide a file from the unix side of things (eg:
invisible to ls ?

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 09/06/2021 21:30, nospam wrote:

In article <Gq8wI.740208$nn2.140676@fx48.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

(I wish there were a feature like on VMS

then go use vms.

helpful...


--
To email me replace 'nospam' with 'el'
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 10/06/2021 08:11, JF Mezei wrote:

Another puzzling one, a behaviour I have not seen before.
High Sierra. Home directory on APFS SSD.

[...]

Unhelpful advice: Upgrade to Big Sur :-)-O

el

--
To email me replace 'nospam' with 'el'
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 10. Jun 2021 at 08:11:46 CEST, "JF Mezei"
<jfmezei.spamnot@vaxination.ca> wrote:

If I try to delete it:
"The Item .MG-9A44E1BB-6071-4B43-B82D-D2828F91546D can't be moved to
the Trash because it can't be deleted. (only button is OK)

Open Terminal

sudo rm "Drag that file in here"

that should get rid of it.


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In message <iioi6hFlpnlU1@mid.individual.net> Bernd Froehlich <befr@eaglesoft.de> wrote:

On 10. Jun 2021 at 08:11:46 CEST, "JF Mezei"
<jfmezei.spamnot@vaxination.ca> wrote:

If I try to delete it:
"The Item .MG-9A44E1BB-6071-4B43-B82D-D2828F91546D can't be moved to
the Trash because it can't be deleted. (only button is OK)

Open Terminal

sudo rm "Drag that file in here"

that should get rid of it.

That will work with files that can be deleted. It is unlikely to work
with a fle that reports it cannot be deleted. It is ossile that the uchg
flag has been set for the file. you can celar it with:

open terminal
sudo chflags -R nouchg <drag the file in to the Terminal>

then try to remove the file.


--
Help me, Obi-wan Kenobi. You're my only hope.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2021-06-14 04:26, Bernd Froehlich wrote:

Open Terminal

sudo rm "Drag that file in here"

that should get rid of it.

Thanks,. neat trink I hadn't thought of.

Alas, my mac crashed yesterday and the unmoveable "non existent" file
is gone from the desktop.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2021-06-14 04:26, Bernd Froehlich wrote:

sudo rm "Drag that file in here"

However, since the Unix view of the file system did not see the file, I
have to wonder if that command would simply return "file not found,
can't be deleted" kind of message.

Is there an "ls" incantation that would show any/all hidden files ?
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

Is there an "ls" incantation that would show any/all hidden files ?

One way to see everything in a directory is to use the find command.

If you cd in Terminal to the directory with the stubbon file, run this:

find .

or if it's a large directory (many files)...

find . | more

I dunno about the mac, finder and all that but there used to be a way of destroying a file via the inodes. The mac seems to support:

ls -i filename

which will return something like:

57835797 zzz

where that number is the inode the file starts at but they seem to have changed/removed the rm -i command which used to be remove the files inode
and changed it to interactive.

The osx find seems to support both the -inum and -delete so something like this:

find . -inum 57835797 -delete

could get rid of it.

Keep in mind that will blow the file out but with Finder and a gui, it
doesn't mean it'll disappear from the desktop.

Odds are when you rebooted it ran fsck, figured the problem out and fixed things, that sort of is the point of it.

-bruce
bje@ripco.com
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2021-06-15 08:33, bje@ripco.com wrote:

I dunno about the mac, finder and all that but there used to be a way of destroying a file via the inodes. The mac seems to support:

ls -i filename

which will return something like:

57835797 zzz

Would the above list files that sudo ls -a didn't show?


BTW, is APFS now suffiently documented to allow 3rd party apps to parse
the APFS file structure , undelete files etc. Such an app might have
been able to give hints on the existence (or lack thereof) of this file
which appeared in Finder on Desktop but nowhere else.

find . -inum 57835797 -delete

Would it be correct to state that all the Unix utilities use the same
interface to the Apple file system that synthetizes Unix file
names/structure and so if ls doesn't know of a file, no other unix
command would? or are there commands that have lower level access to the
APFS file system?


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

Would the above list files that sudo ls -a didn't show?

It's really a "more than one way to skin a cat" possibility.

The main difference would be the find command would show the contents of a directory, if one is in the directory you are using find on, where ls is
just showing the directory name.

You also don't get any permission or ownership info with find.

So it (find) could show something that ls isn't. Or not.

Would it be correct to state that all the Unix utilities use the same interface to the Apple file system that synthetizes Unix file
names/structure and so if ls doesn't know of a file, no other unix
command would? or are there commands that have lower level access to the
APFS file system?

I don't know the answer to that but one thing I haven't seen mentioned is
that .DS_Store file. As far as I know, the osx finder reads from there to
show what things are. I guess it's a mini database of sorts. Somewhere osx
must scan drives, directories, files to create a fast way of seeing in the finder and make updates as things change.

I'd guess from the original complaint that finder was showing something that didn't exist within the file system. The .DS_Store file maybe had some corruption.

Wonder if the .DS_Store file was simply deleted and let the osx rebuild it wouldn't of fixed the problem also.

Just pointing out that Finder (the gui) is not the same as looking at the
file system through Terminal.

-bruce
bje@ripco.com
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In message <saavq7$58s$1@remote6hme0.ripco.com> bje@ripco.com <bje@ripco.com> wrote:

I don't know the answer to that but one thing I haven't seen mentioned is that .DS_Store file. As far as I know, the osx finder reads from there to show what things are. I guess it's a mini database of sorts.

No, the .DS_Store files contains metadata about the folder display
settings for the finder window. Things like position on screen, list
view, sort selection, dimensions, state of the sidebar, etc.

It has no other function.

I'd guess from the original complaint that finder was showing something that didn't exist within the file system. The .DS_Store file maybe had some corruption.

It is impossible to guess with JF.

Wonder if the .DS_Store file was simply deleted and let the osx rebuild it wouldn't of fixed the problem also.

Nope, it has nothing to do with files.

Just pointing out that Finder (the gui) is not the same as looking at the file system through Terminal.

Of course not, but JF lacks some very basic understanding and is
constantly saying inane things about the filesystem that shows he is
quite clueless about how it works.

--
Reality is a curve. That's not the problem. The problem is that there
isn't as much as there should be. According to some of the more
mystical texts in the stacks of the library of Unseen University
- (...) - at least nine-tenths of all the original reality ever
created lies outside the multiverse, and since the multiverse by
definition includes absolutely everything that is anything, this
puts a bit of a strain on things. --Moving Pictures
--- Synchronet 3.18b-Win32 NewsLink 1.113