14

I have made a small app for a client. The app scans a files directory which contains several text files. It then reads each file into a string. Every file has a title and the article text. The two parts are separated with a pipe character like this: article_title|article_text. The script displays a list of links to open each article. The text of the link is the same as the article title.

Now, the client has apparently deleted an article, but is seeing an entry for the deleted file like the image bellow:
enter image description here

I searched for the string on the web and could actually find pages showing similar strings, e.g. here which is apparently a deleted blog post.

What could be the cause for this? Is the file really deleted?

P.S.

  1. The client has set the app on an intranet and cannot give me access, he sent me a screenshot.
  2. I also don't know what his server OS is.
  3. I'm not sure what to tag this question, maybe you can change the tags to better ones.
Majid Fouladpour
  • 29,356
  • 21
  • 76
  • 127
  • It could be some random Unix thing? What are you using to scan the directory? Does `glob()` give you the same thing? – alex Apr 11 '11 at 05:06
  • 2
    Oh wow, this is an interesting one... – Charles Apr 11 '11 at 05:09
  • I'm using `$files = scandir('./files/');` and then use a `foreach` loop to read the file names. I have no access to the client's intranet to probe it further. – Majid Fouladpour Apr 11 '11 at 05:09
  • Hard to tell from a screenshot. But the `?@` looks like it might be UCS2/UTF16 intermingled with some ASCII strings. When a similar sequence appears on other websites, I would preclude a damaged filesystem. Might be just an application that writes to temporary files with corrupt filenames. – mario Apr 11 '11 at 05:17
  • @mario - We actually have `content="text/html; charset=UTF-8"` header in the article lister and it does succeed in getting the characters right. But the `question-mark-diamonds (what are they called by the way?), suggest the system does not have the required charset to display them correctly. I might be wrong though. – Majid Fouladpour Apr 11 '11 at 05:25
  • The diamond question marks could just be NUL bytes `\0`. Setting the page output to UTF-8 won't convert the binary sequences into that. Could be anything. This will remain a riddle with just the screenshots. – mario Apr 11 '11 at 05:29
  • Seems like a file actually has that content. Can all the files be checked to see that the content (or some equivalent garbage) is not in a file? – Sajid Apr 11 '11 at 05:31
  • I have sent the client an altered script which uses `glob()` as suggested by alex. Waiting for him to provide more info. But even if the display problem is fixed by using `glob()`, we are just hiding some filesystem issue. Too bad I have no direct access. – Majid Fouladpour Apr 11 '11 at 05:44

3 Answers3

22

OK, I found what it is. One of the Google search results pointed to this Which contains the following:

Bud1  ... @Ђ @Ђ @Ђ @E DSDB `Ђ @Ђ @Ђ @

Interestingly, the file is a .DS_Store file! I checked a few .DS_Store files and they all contained the mysterious characters. These (hidden) files are generated automatically by Mac OS X. So the client should have accessed the folder from console and caused the creation of the hidden DS_Store (remember it's an intranet).

Majid Fouladpour
  • 29,356
  • 21
  • 76
  • 127
3

For people that is still getting trouble with this in your application (after removing a file in my case), I solved it by removing recursively the .DS_Store files in the project folder.

On terminal, go to the project:

cd to/your/directory

And just type:

find . -name '.DS_Store' -type f -delete

credits to Jon Bellah on his blog https://jonbellah.com/articles/recursively-remove-ds-store/

Edilson Borges
  • 549
  • 4
  • 11
2

This is information that the Finder (Mac equivalent of Windows Explorer) stores about files and folders. The best description of the format I found was here:

https://metacpan.org/pod/Mac::Finder::DSStore

The format is described as:

The .DS_Store file holds a series of records giving attributes of the files in the directory or of the directory itself (referred to as .). These records are stored in a B-tree, and the pages of the B-tree are stored in the file by a "buddy allocator" along with a small amount of metadata. The allocator also provides a level of indirection, from small integers to file offsets, presumably allowing blocks to be relocated as they grow and shrink.

Majid Fouladpour
  • 29,356
  • 21
  • 76
  • 127
Andre M
  • 6,649
  • 7
  • 52
  • 93