Hi, I hope this is a reasonable forum to post this question to.

I'm compiling and using KDE 5 under WIndows 7. Specifically, I've gotten Qt, "frameworks" and "kde-baseapps" to compile and work using MS Visual C++ 2013. However, I didn't realize that the tagging functionality appears to run directly through Baloo (which I suppose makes sense, even with a move to extended attributes). I tried building Baloo but have run into issues.

Is anyone in this forum aware of work being done to get Baloo working in Windows when compiled with MSVC 2013? Should I ask in the OS specific forum?

I see ifdefs in kfilemetadata and baloo source code for unix-like OSes but no indication of any Windows specific configuration.

Thanks in advance!

KFileMetaData is currently used for tagging. It is just a light wrapper on top of xattr system calls. These xattr calls will fail on file systems which do not support xattr. AFAIK NTFS does not support it.

What problems did you encounter with Baloo?

Btw, from my point of view, it doesn't make sense to use Baloo on Windows since Window Search is much better suited for the task. It's better to use the existing index. However, this is not a trivial task, specially since many KDE applications use Baloo. and they would need to be ported.

NTFS has extended attributes, the system calls and implementation differ in general with extended attribute data going into $EA and $EA_INFORMATION in the master file table (MFT). I'm relatively new to this stuff however, to my knowledge, this is how Windows handles marking files as being from an external resource such as a website to provide a warning that such files might harm your computer.

I think it would be fairly simple to modify KFileMetaData to support Windows and I may do so. If it works well I can certainly send patches along for consideration.

The problems were simply in compiling it without being able to compile kfilemetadata etc.

You make an interesting point. Perhaps on Windows Baloo could act more as a wrapper to the Windows Search functionality? That might be a very nice solution? Does Baloo interact with Spotlight on OS X?

Thanks for your insight.

salve.nauta wrote:NTFS has extended attributes, the system calls and implementation differ in general with extended attribute data going into $EA and $EA_INFORMATION in the master file table (MFT). I'm relatively new to this stuff however, to my knowledge, this is how Windows handles marking files as being from an external resource such as a website to provide a warning that such files might harm your computer.

I think it would be fairly simple to modify KFileMetaData to support Windows and I may do so. If it works well I can certainly send patches along for consideration.

Windows patches would be most welcome.

You make an interesting point. Perhaps on Windows Baloo could act more as a wrapper to the Windows Search functionality? That might be a very nice solution? Does Baloo interact with Spotlight on OS X?

The kde-mac team also contacted me about something similar. We need someone to work on both windows and mac. However I do not want Baloo to be a wrapper on top of search infrastructure. Baloo is a file indexing + searching solution for Linux. That's it.

If we need a wrapper a new library can be created which sits on top of Baloo / Windows Search / Spotlight / Tracker. Someone needs to do this.

vHanda wrote:
The kde-mac team also contacted me about something similar. We need someone to work on both windows and mac. However I do not want Baloo to be a wrapper on top of search infrastructure. Baloo is a file indexing + searching solution for Linux. That's it.

If we need a wrapper a new library can be created which sits on top of Baloo / Windows Search / Spotlight / Tracker. Someone needs to do this.

This seems like a very good idea.

There is great variation across OSes in handling of extended attributes as well as in handling of search. Wrapper(s) could smooth out/handle many issues for cross-platform implementation.

For interested parties and those who might have comments, the following is what I have found out as of now from my research. I put this here as this information seems key to the possible implementation of wrapper(s). I plan to experiment a bit more with Windows Search before forging ahead with implementing something myself.

With regard to extended attributes:

OS X and Unix-like OSes appear fairly similar and stable at this point as I'm sure you're aware. Extended attributes are widely used and there is clear structure in definition and handling (e.g. system.*, user.* ... for Linux and FreeBSD, com.apple.metadata:* among others for OS X).

Windows feels messier and less focused. Each NTFS file can have a ::$EA stream (type) which provides a sort of "traditional" extended attributes implementation (originally for compat with OS/2 and HPFS, but now being used for client-side caching at least by Windows itself). Files can also have "Alternate Data Streams" (ADSes), this is actually where the information "Zone.Identifier" goes that indicates a file came from a remote system. The ADSes seem (at the OS level) to be most like the OS X 10.9+ version of extended attributes (named "forks" now supporting storage of up to 2GiB). The $EA stream type contains attributes that are more limited size-wise (64 KiB in total across all?) and seems most similar to OS X prior to 10.9 (128 KiB - per file?) as well as implementations of xattrs in filesystems such as Btrfs (up to 4 KiB each?).

Copying (cmd, explorer, cygwin), syncing (e.g. cygwin), and such appears to behave fairly well with respect to $EA in Windows 7+. A lot of software (perhaps unsurprisingly) doesn't respect $EA if you're not simply changing the data of the existing file. That is, if you "save as...".

With regard to search:

In the Windows world, a different approach from extended attributes has largely been pursued for metadata. Beginning with Windows Vista, Windows OSes use the "property system", in which metadata is expected to be placed inside the file, avoiding the issue of what happens when files cross boundaries (this goes together with development of XMP as a sort of band-aid to try to extend embedding of metadata to file formats beyond those that originally/natively embed metadata). The IFilters and property handlers in Windows that provide info to explorer and the indexing system work in this model. I have not yet found a way to pull entries from $EA using Windows explorer and it looks to me right now as though it might be necessary to write a wrapper that could be put around various property handlers (for example) in order to get Windows Search to index items like tags stored under $EA. There is already some code that might be leveraged (http://filemeta.codeplex.com/releases/view/121762). Windows Search also seems not to handle ADSes just FYI in terms of this being a potential alternative implementation.

Incidentally, OS X has implemented many solutions through the years for dealing with extended file attributes including conversion to ADSes when copying to SMB mount points, the use of AppleDouble files, etc. to try to deal with many of the issues with extended attributes.

EDIT: lest I forget though, some decisions were already taken with respect to dropping support for tags on other systems: http://vhanda.in/blog/2014/08/extended- ... s-updates/ rather than providing poor or potentially user unfriendly support.

Hi,

I'm really sorry to go off topic on here..
I'm trying to compile kde on win7 myself and having no luck, and chance you could tell me how you got it to compile with msvc2013?

thanks. there doesn't seem to be much updated info about and this is the only post i've found that is at all recent =/