Page MenuHome

WIP: File Attributes and Linked Files
Needs ReviewPublic

Authored by Harley Acheson (harley) on Tue, Feb 4, 1:35 AM.
"Like" token, awarded by mswf."Love" token, awarded by ankitm."Like" token, awarded by Tetone."Like" token, awarded by billreynish.
This revision needs review, but there are no reviewers specified.



This is an attempt to support file attributes in a way that can work with all platforms, including symlinks. I'm hoping to (finally) do "hidden" files and folders in a way that works for all platforms. And also hoping to easily support things like Mac Aliases.

This is a work in progress so some things don't work yet as I'm still working out the best way to do things. But from Windows it is properly showing folder decorations for items that are system, hidden, read-only, and those with reparse points like Soft links and Junction Points:

see and for its breakdown. Former goes in first, and makes the foundation for latter.

Diff Detail

rB Blender
arcpatch-D6743 (branched from master)
Build Status
Buildable 6555
Build 6555: arc lint + arc unit

Event Timeline

Now does hidden files properly for all platforms. So only hides/shows Windows files based on file attributes. For other platforms it does check those (Linux Readonly and Mac Invisible) but then checks for leading dot and trailing tilde.

Just better comments.

Looks pretty on Windows. Seems to do everything while in Thumbnail mode. In regular list view it does indicate links, but does not show hidden files as dimmed. Not sure how to do that yet. LOL

Now drawing the small folder icons in list view as dimmed it hidden (but showing hidden)

Should dim hidden files and folders on Mac and Linux now (if filename starts with dot). Other misc changes.

Mostly comment changes.

Renaming an emum. Using FILE_ENTRY_ALIAS rather than FILE_ENTRY_SHORTCUT

This is a pretty extreme (and ugly) example since Windows user home folders are a mess of hidden, read-only, and redirected folders. But "show hidden" in Blender does match that seen in the file system.

Now have a way to handle file-type redirections like Mac Aliases.

Hey @Campbell Barton (campbellbarton)!

I'm a bit stuck on how this could/should be refactored...

I have started by defining a bunch of common file attribute flags. I repurposed FileDirEntry.flags as "attributes" since it only had one bit in use. Then it is just populating those flags early so they can be cached. I added an extra member to the FileDirEntry structs to hold an optional string for items that might have a link target that is different from its own location - only applicable to Mac Alias or to Windows shortcut (lnk) files.

With this patch applied on all platforms we see hidden files and folders dimmed (if viewing hidden files). This required some slight changes to hidden file function so I could tell if something is hidden even if not filtering hidden.

On Windows we further see system and readonly folders marked with special icons. And the different types of symlinks (hard links, soft links, mount points, volume mounts) are shown with a little arrow. This means on Windows we see a display in the file browser that very closely mirrors how special folders are shown in the operating system. Although not certain how useful the "read-only" marking on folder is since that attribute seems to be sprinkled around my hard drive in odd ways and never keeps me from saving in them, Might remove that decoration.

I have marked some "TODO"s where file attributes could be read in other platforms, and where Mac Aliases could be dealt with.

But I'm not sure you'd like all these platform-specific things all over the place here, but not sure where to deal with it all. I can imagine things like getting file attributes could be in Ghost calls, but then would have to duplicate my flags. Blenlib storage.c might make sense since it already contains platform-variant low-level file operations. But then I see we have (yet another) direntry defined in BLI_fileops_types.h so there is even the idea of extending that also with attributes and gathering that information every time we call stat().

So yes, mostly just stuck on how (or if) I should proceed. Or if you even like the idea.

Complaint of how hidden files are currently dealt with:

Small changes to simplify dealing with hidden. More todo notes for Mac attributes.

Ankit (ankitm) updated this revision to Diff 21560.EditedMon, Feb 10, 4:40 AM
Ankit (ankitm) edited the summary of this revision. (Show Details)
  • Working for aliases on mac. entry->fullname can be discarded in favour of a temporary variable. It's memory also need to be tracked and cleaned up.
  • Need to see if manual reference counting is better than ARC here in
Brecht Van Lommel (brecht) requested changes to this revision.Fri, Feb 14, 6:30 PM

Functionality and code seems generally, mostly comments about making the implementation a bit nicer.


These PATH_MAX definitions can get out of sync and are not clearly corresponding to limits in the rest of Blender.

Instead add a int targetPathMaxLength parameter to resolveFilePath, and remove all #define PATH_MAX.


Rather than a bool array, you can define a struct GHOSTFileAttributes with proper names for each member.


int -> bool and return true and false.


I don't think anything needs to be logged here with NSLog.

There are GHOST logging functions, but that would produce potentially too much output when browsing files.


This implementation could be move to GHOST then as well, since the macOS one is there.

This revision now requires changes to proceed.Fri, Feb 14, 6:30 PM

@Brecht Van Lommel (brecht) :

This last revision of this patch is actually from @Ankit (ankitm) with the Mac stuff, so is hard for me to address.

My hope, with the other (non-WIP) patch ( is to remove some of this complexity and do it is such a way that moves some of this platform-specific stuff to storage.c, since that already contains low-level platform-varying file routines.

If the other gets in then I would help ankitm with a separate patch that could add Mac attributes and deal with Mac Aliases.

Ok, this is a bit confusing.

@Ankit (ankitm) could comandeer this patch and update it, or reopen the original patch. Doesn't really matter to me either way, I just need to know which patch to review for the macOS changes.

This revision now requires review to proceed.Mon, Feb 17, 12:20 PM

Ok, this is a bit confusing.

Is why this has “WIP” in title and has no assigned reviewers.

The review of should help answer if the Mac stuff needs to go in ghost or just in storage.c