tracker copies additional bfs data onto ntfs drive but it shouldnt

[streak]

tracker copies additional bfs data onto ntfs drive but it shouldnt.

[streak]

copied file from bfs to ntfs cant be moved on ntfs drive, because of unknown "protection error".

how to reproduce:

copy any file from bfs to ntfs, and then log into windows and try to move that file from one directory to another. Windows will not move a file.

[michaelvoliveira]

Yeah.. this occours with me too

the best solution is reset to Ubuntu, and move/copy from there...

[aldeck]

I doubt this is a Tracker bug, though i can't test. Does it happen also when copying (bfs -> ntfs) from terminal?

I didn't know our ntfs addon supported copying attributes, btw, on Windows, is the failing copy destination on a fat32 partition by any chance? That would explain the Windows message. An NTFS file can have multiple streams inside the same file (i.e. meta-data / attributes), FAT doesn't support multiple streams, so you will loose the alternate streams.

(Note for another ticket: we might want to add the same kind of alert in Haiku when copying data to an attribute-less filesystem)

[stippi]

Using the attribute facilities of NTFS is quite cool. For example, it would allow you to store media files with meta data on a volume that other operating systems can read without hassle. There are multiple factors here:

• The attribute support in our NTFS file system add-on is not finished, AFAIK. It should be finished first and perhaps disabled for the time being if noone has time to work on it right now.

• From the ticket description/comments, I would say the file was moved from one directory to another on the same volume. If Windows behaves this way, then the whole idea, neat as it is, is screwed and we need to disable this feature. I have a patch in my local tree which disables this.

• If on the other hand the copy was attempted from NTFS to FAT, then I'd say the warning is fine and we can keep the feature enabled. It doesn't look like it's the case, though.

[korli]

Replying to stippi:

• If on the other hand the copy was attempted from NTFS to FAT, then I'd say the warning is fine and we can keep the feature enabled. It doesn't look like it's the case, though.

NTFS to FAT (or any FS other than UDF) triggers this confirm dialog on Windows Explorer when additional streams are detected. This is a documented behavior and isn't specific to files coming from BFS.

[Disreali]

Replying to streak:

copied file from bfs to ntfs cant be moved on ntfs drive, because of unknown "protection error".

copy any file from bfs to ntfs, and then log into windows and try to move that file from one directory to another. Windows will not move a file.

This issue has been around a long time. In fact, I remember that BeOS had similar issues.

Replying to stippi:

Using the attribute facilities of NTFS is quite cool. For example, it would allow you to store media files with meta data on a volume that other operating systems can read without hassle. There are multiple factors here:

• The attribute support in our NTFS file system add-on is not finished, AFAIK. It should be finished first and perhaps disabled for the time being if noone has time to work on it right now.

• From the ticket description/comments, I would say the file was moved from one directory to another on the same volume. If Windows behaves this way, then the whole idea, neat as it is, is screwed and we need to disable this feature. I have a patch in my local tree which disables this.

• If on the other hand the copy was attempted from NTFS to FAT, then I'd say the warning is fine and we can keep the feature enabled. It doesn't look like it's the case, though.

IME, this issue is intermittent, sometimes files copied form a bfs volume have no problems on a ntfs volume, though most times the problem happens. I've only copied files from a bfs volume to a ntfs volume.

If you have a patch that disable the attribute support, please attach it.

[Disreali]

Anyone looking into this?

[pulkomandy]

There is no clear reply from Windows users here. Does the "stream loss" alert only happen when copying to FAT, or also when copying between NTFS volumes? (this is not about the initial copy done from Haiku, which is alwas from BFS to NTFS).

• If the alert is only shown in Windows when copying to FAT, then we don't need to do anything: Windows is warning that the attributes will be missing from the copy, and ightfully so.
• If the alert happens also when copying/moving between NTFS volumes (or inside the same volume) then it is more annoying: it means Windows isn't able to preserve the attributes in that case, even if the filesystem allows it. In that case, the attributes are less useful, but still not completely useless, so I'm not sure what we should do.

[pulkomandy]

I'm closing this because the problem is actually (maybe) Windows not handling extended attributes. We can't fix their code.

[ttcoder]

(adding this closed ticket to my "knowledge base" : NTFS 'streams' are supported, to preserve attributes in a better way than ext2 "xattrs" do, neat!)