Hi, On Tue, 22 Mar 2016, Richard Brown wrote:

Typically, I think the openSUSE Project tries to avoid shipping software that can break your machine...

Huh? Since when? That doesn't make sense.

So I don't think we have a naming convention for doing it..

That's true, though. -quarantined suffix sounds a bit unwieldy. -extra?

Not sure we want one either..why would someone need these quarantined features?

Why would we want to decide what users want? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

22.03.2016 22:38, Greg Freemyer пишет:

The one I best understand is ntfsfallocate.

Basically the issue is NTFS-3G provides a non-backward compatible feature.

With fallocate in general you can allocate large files that you can latter fill in. Often done for the virtual disk in a VM as an example. In a matter of seconds you can allocate data blocks for a 100GB file. By doing it that way you reduce fragmentation, and also only take a relatively short period of time to create the file. (Who wants to wait minutes for a 100GB file to be zero-filled).

ntfsfallocate allows that same behavior with the NTFS filesystem. The NTFS-3G driver in turn understands what is going on and can work with the file as data is later written to the allocated blocks.

Windows on the other hand does not understand the data structure layout created by ntfsfallocate, and thus it can cause a problem.

I wonder - NTFS supports sparse files; what ntfsfallocate does that cannot be mapped to it?

(Per the documentation. I haven't tested it.)

The ntfsfallocate man page says you have to fill all of the allocated space with data in the Linux environment before the metadata / data layout is functional in Windows.

=== Thus a feasible use case might be to build a virtual drive for a VM in Linux on a NTFS filesystem, then try to run that VM in Windows. You will get a failure mode until all the individual data blocks have been written to at least once, but some users may find that an acceptable situation.

Greg

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 22 Mar 2016 21:01, Andrei Borzenkov wrote:

22.03.2016 22:38, Greg Freemyer пишет:

...

The one I best understand is ntfsfallocate.

Basically the issue is NTFS-3G provides a non-backward compatible feature.

With fallocate in general you can allocate large files that you can latter fill in. Often done for the virtual disk in a VM as an example. In a matter of seconds you can allocate data blocks for a 100GB file. By doing it that way you reduce fragmentation, and also only take a relatively short period of time to create the file. (Who wants to wait minutes for a 100GB file to be zero-filled).

ntfsfallocate allows that same behavior with the NTFS filesystem. The NTFS-3G driver in turn understands what is going on and can work with the file as data is later written to the allocated blocks.

Windows on the other hand does not understand the data structure layout created by ntfsfallocate, and thus it can cause a problem.

I wonder - NTFS supports sparse files; what ntfsfallocate does that cannot be mapped to it?

It's a matter of versions. When "NTFS-Sparse" was introduced in NT5 / Windows 2000 for MS-SQL databases. From then, and during the time of Windows XP / Windows 2003 it had a different behavior than it has since Windows 8.1 / Windows 10. (I have no data for Vista and Win7). A NTFS-Sparse file has a special attribute set [1], and can not be converted into a "normal" file until all holes are filled / the file completly written at least once. [code from MS Windows] fsutil sparse setflag <filename> [/code] [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa364596(v=vs.85).as... [2] http://msdn.microsoft.com/de-de/library/cc755441.aspx [3] http://msdn.microsoft.com/de-de/library/ms175823.aspx So, the danger immanent is: on what Windows version will the filesystem used next? How will that Version handle sparse files? It's not a matter of (support) yes or no, or even language (ntfs), but a matter of dialect (Windows version). Windows 10 handles things on NTFS misbehavior much more graceful than Windows 7 for example. And before Vista is another kettle of fish. google hint: "NTFS-Sparse" - Yamaban.

Hi, On Tue, 22 Mar 2016, Ludwig Nussel wrote:

...

The ntfs-3g_ntfsprogs program does not currently include some of the more dangerous utilities that it could include.

WIth "./configure --enable-quarantined" several "dangerous" utilities get built and installed.

Given they are dangerous and possibly can destroy data I don't want to put them in the main ntfs-3g_ntfsprogs package.

What about installing the tools in question to e.g /usr/lib/ntfsprogs/quarantined instead of somewhere in $PATH? No need for an extra package then.

Binaries callable by users belong to {,/usr}/{,s}bin, not somewhere hidden. Why should the tools be hidden at all? I can use all kinds of programs to do dangerous things. dd, rm, vim, cp, su, fsck, debugfs. It simply makes no sense to attach a tag "dangerous" (what btw. would be the criteria for this?) to some programs and then do crazy packaging stunts based on that. I wouldn't even put them in a different package. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org