Opened 9 years ago

Last modified 2 years ago

#6597 assigned bug

tracker copies additional bfs data onto ntfs drive but it shouldnt

Reported by: streak Owned by: nobody
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/Development
Keywords: Cc: mdisreali@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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

Attachments (1)

streamloss.JPG (23.1 KB) - added by streak 9 years ago.

Download all attachments as: .zip

Change History (11)

Changed 9 years ago by streak

Attachment: streamloss.JPG added

comment:1 Changed 9 years ago by 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.

comment:2 Changed 9 years ago by streak

Component: - GeneralApplications/Tracker
Owner: changed from nobody to axeld

comment:3 Changed 8 years ago by michaelvoliveira

Yeah.. this occours with me too

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

comment:4 Changed 8 years ago by 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)

comment:5 Changed 8 years ago by 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.

comment:6 in reply to:  5 Changed 8 years ago by 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.

comment:7 in reply to:  1 Changed 8 years ago by Disreali

Cc: mdisreali@… added
Version: R1/alpha2R1/Development

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.

comment:8 Changed 8 years ago by Disreali

Anyone looking into this?

comment:9 Changed 4 years ago by 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.

comment:10 Changed 2 years ago by axeld

Owner: changed from axeld to nobody
Status: newassigned
Note: See TracTickets for help on using tickets.